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ABSTRACT 


The  effective  use  of  information  can  enable  a  public  agency  to  better  serv’e  the 
taxpayers,  or  provide  a  crucial  strategic  advantage  for  a  private  sector  firm.  Present  U. 
S.  Coast  Guard  information  systems  do  not  provide  information  to  all  potential  users  as 
effectively  as  they  could.  They  suffer  from  several  shortcomings: 

•  Poor  connectivity,  resulting  in  an  awkward,  torturous  information  flow  which 
frequently  does  not  provide  information  to  people  who  need  it. 

•  Significant  overlap  in  content,  resulting  in  increased  workload  and  frustration  for 
field  personnel  who  enter  data  and  data  inconsistencies  between  applications. 

•  Poor  user  interface  designs,  resulting  in  a  situation  where  although  information  may 
be  accessible  to  a  user,  it  is  difficult  to  retrieve  and  therefore  not  gotten. 

Cross-functional  systems,  based  on  a  robust  information  architecture,  offer  the 
potential  to  dramatically  improve  information  flow  and  availability  within  an  organization. 
In  the  Coast  Guard,  the  flow  of  operational  information  can  be  greatly  improved  by 
developing  a  cross-functional  Operations  Information  System  (OIS).  Developing  such 
a  system  is  critical  to  continued  effective  service  to  the  public,  but  may  require  changes 
in  the  ways  in  which  systems  are  developed  and  funded. 
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1.  INTRODUCTION 


Numerous  studies  have  documented  that  the  U.S.  has  been  in  the  throes  of  an 
historic  transition  for  the  past  two  decades.  The  old  industrial  society  that 
generated  wealth  in  the  form  of  capital  goods  and  manufactured  products  is  giving 
way  to  a  new  society  valued  in  terms  of  intangible  assets,  such  as  knowledge  and 
information  processing.  (Business  Week,  June  30,  1980). 


Firms  preparing  to  meet  the  challenges  of  the  1980's  will  need  a  capable  and 
sophisticated  manager  of  corporate  information.  An  organization's  success  will  be 
dependent  in  large  part  on  successfully  managing  its  information  resources.  (Lucas, 
1979,  p.  114). 


As  predicted  by  the  first  quote,  and  like  many  government  agencies  and  businesses, 
the  United  States  Coast  Guard  is  increasingly  discovering  the  strategic  importance  of 
information.  But  it  is  also  discovering  the  deep  implications  of  the  second  quote  — 
namely,  that  it  is  not  information  in  itself,  but  the  effective  use  of  that  information,  that 
is  critically  important.  The  effective  use  of  information  can  provide  private  sector  firms 
with  significant  competitive  advantages.  In  a  similar  fashion,  it  can  greatly  increase  the 
effectiveness  of  a  government  agency's  service  to  the  taxpayers. 

Achieving  this  effective  information  use,  however,  is  exceedingly  complex.  Many 
existing  information  systems  fall  short  of  their  potential  effectiveness,  for  a  variety  of 
reasons.  And  almost  no  organization  has  implemented  a  single  system  that  integrates  all 
facets  of  its  operations.  The  Coast  Guard  today  finds  itself  in  this  situation  —  it  has  a 
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large  number  of  information  systems  in  use,  but  no  single  system  that  summarizes 
information  from  all  functions.  Today's  systems  are  fairly  successful  at  collecting  the 
information  their  designers  specified,  which  is  primarily  for  use  by  headquarters  staffs. 
However,  few  offer  their  information  to  those  staffs  with  any  flexibility  in  presentation, 
and  few  distribute  any  of  the  information  to  other  levels  in  the  organization  for  use  in 
operational  planning  or  command  and  control.  There  is  a  great  need  for  information  to 
flow  not  only  up  the  hierarchy,  but  also  down  it,  as  well  as  across  the  traditional 
functional  lines  within  the  organization. 

There  are  two  reasons  for  the  present  situation.  First,  most  Coast  Guard  systems 
are  typical  of  1980's  computing  technology,  in  which  only  a  few  exceptional  systems 
provided  the  complete  information  flow  now  possible.  Second,  information  "owners"  are 
sometimes  reluctant  to  share  it,  since  it  represents  organizational  power.  This 
"information  parochialism"  is  present  in  the  Coast  Guard. 

A.  COAST  GUARD  PROGRAMS  AND  PROGRAM  MANAGERS 

The  Coast  Guard  is  responsible  for  four  major  roles;  maritime  law  enforcement, 
national  security,  maritime  safety,  and  marine  environmental  protection  (COMDTINST 
16000.21,  21  Sep  90).  The  first  two  each  constitute  operating  Coast  Guard  "programs" 
of  their  own.  Maritime  safety  includes  several  programs,  including  search  and  rescue, 
aids  to  navigation,  boating  safety,  vessel  inspection  and  documentation,  and  icebreaking. 

Each  of  these  programs  is  administered  by  a  program  manager  at  Coast  Guard 
Headquarters  (CGHQ).  These  officers  and  their  staffs  perform  planning,  programming, 
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and  budgeting  for  their  respective  programs,  and  are  assisted  by  other  "support"  offices. 
The  organizational  structure  at  headquarters  and  in  lower  echelon  staffs  is  a  classic 
hierarchy,  divided  along  functional  lines. 

B.  RESEARCH  APPROACH 

The  goal  of  this  thesis  is  to  make  recommendations  to  increase  the  effective  use  of 
information  by  the  Coast  Guard,  partly  by  a  critique  of  existing  systems.  Rather  than 
consider  the  entire  suite  of  Coast  Guard  applications,  the  thesis  examines  a  few 
representative  systems,  listed  in  Table  1.  They  were  chosen  for  their  mainstream  position 
in  the  Coast  Guard's  suite  of  operational  systems. 


TABLE  1;  COAST  GUARD  PROGRAM  MANAGERS  AND  INFORMATION 
SYSTEMS. 


Program: 

Program  Manager: 

Information 

System: 

Search 

and 

Rescue 

G-NRS 

Office  of  Navigation  Safety 
and  Waterways  Management, 
Search  and  Rescue  Division 

SAR  database 
(data  input  via 
SARMIS/DES, 
SARMIS/DSS) 

Law 

Enforcement 

G-OLE 

Office  of  Operations, 

Law  Enforcement  Division 

LEIS 

(data  input  via 
SEER,  SIMS/ELT) 

Marine 

Safety 

G-M 

Office  of  Marine  Safety, 
Security, 

and  Environmental  Protection 

MSIS 

3 


The  information  systems  included  in  this  study  are  all  intended  primarily  for 
decision  support.  They  include  transaction  processing  as  a  necessary  means  of  data 
capture,  but  the  bottom-line  reason  for  their  existence  is  that  someone  needs  the 
information  for  decision  making.  The  decisions  to  be  made  vary  in  type,  but  can  be 
broken  down  into  two  broad  classes  for  purposes  of  analysis  (although  most  systems  are 
used  to  some  extent  for  both  decision  types). 

The  first  category  is  decisions  made  at  the  operational  and  tactical  levels.  These 
are  primarily  command  and  control  decisions,  cither  in  the  short  term  or  medium  term. 
A  typical  short-term  decision  supported  by  MSIS  is  whether  or  not  to  perform  a  boarding 
on  a  particular  vessel.  The  information  required  includes  the  recency  of  the  last  boarding, 
results  of  prior  boardings,  and  any  other  information  about  the  vessel.  A  typical  medium 
term  decision  is  whether  to  stage  a  boat  or  aircraft  in  a  place  where  there  normally  would 
not  be  coverage;  the  information  required  includes  the  density  and  frequency  of  cases  in 
that  area  at  certain  critical  times  of  the  week  or  year. 

The  second  category  is  decisions  made  at  the  strategic  level,  primarily  programming 
and  budgeting. 

C.  FUNCTIONALITY  OF  0PEIL\T10NAL  SYSTEMS 

The  existing  operational  information  systems  arc,  for  the  most  part,  fairly  mature. 
Each  of  the  systems  considered  in  detail  here  has  been  operational  since  the  early  to  mid 
1980's.  They  function  fairly  reliably,  and  the  information  they  seek  is  collected  with 
relatively  low  error  rates,  at  least  when  compared  to  the  manual  systems  they  replaced. 
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(For  instance,  the  SIMS/ELT  program  provides  on-line  validation  during  data  entry, 
keeping  error  rates  low.  However,  data  entered  via  manually  prepared  SEER  messages 
is  frequently  erroneous). 

Existing  systems  are  still  primarily  aimed  at  collecting  data  for  a  limited  range  of 
uses  at  headquarters.  Few  allow  any  flexibility  in  their  reports,  or  any  interactive 
manipulation  of  the  data  to  a  form  that  would  suit  the  user.  Similarly,  few  provide  any 
decision  support  to  mid-level  planners  and  operational  personnel,  where  information 
could  be  extremely  important  to  the  agency's  mission  execution.  Those  that  do  provide 
this  type  of  support  are  difficult  to  learn  and  use  effectively. 

The  existing  generation  of  standalone  systems  could  be  made  much  more  effective 
on  their  own  merits  if  improvements  were  made  in  four  key  areas: 


•  Human  interface  —  users’  ability  to  learn  the  system  quickly  and  use  it  easily  once 
learned. 

•  Information  accessibility  —  systems  should  provide  information  in  any  form 
desired  by  the  user,  and  make  it  easy  for  the  user  to  describe  what  is  desired.  They 
should  provide  information  to  users  at  all  organizational  levels,  not  just  the  top. 

•  Data  communications  —  records  should  be  transmitted  to  the  central  database 
before  the  value  of  the  information  decreases  because  of  its  age.  The  simple 
transmission  of  data  should  not  cause  users  delay  or  frustration,  but  rather  should 
be  transparent. 

•  Source-level  data  validation  —  records  should  be  verified  for  accuracy  at  the 
source,  leaving  only  minimal  need  for  validity  checking  at  the  central  site  (i.e.,  to 
check  for  errors  introduced  during  transmission). 


Chapter  III  will  discuss  these  aspects  of  the  Coast  Guard's  information  systems  in 


detail. 


5 


D.  CROSS-FUNCnONAUTY  OF  OPERATIONAL  SYSTEMS 

As  a  result  of  the  individualized  system  development,  with  no  coordination  between 
program  managers,  there  is  little  connectivity  and  no  cross-functionality  between  Coast 
Guard  information  systems.  In  its  1990  report  on  Coast  Guard  Information  Resources 
Management,  the  General  Accounting  Office  (GAO)  writes  that: 

During  the  1980's,  the  Coast  Guard  acquired  new,  expanded  responsibilities  - 
most  notably  drug  enforcement  and  defense-related  activities  -  in  addition  to  its 
traditional  missions  of  search  and  rescue,  marine  environmental  protection,  law 
enforcement,  and  defense  readiness.  In  this  multimission  environment,  the  Coast 
Guard  depends  on  getting  large  amounts  of  information,  getting  it  accurately,  and 
getting  it  on  time.  In  many  cases,  however,  information  is  not  collected,  readily 
available,  or  easily  transferable  among  various  Coast  Guard  units.  These  problems 
have  affected  both  program  operations  and  program  management. 

The  Coast  Guard's  law  enforcement  program,  for  example,  suffers  from  a  lack 
of  readily  accessible  information  necessar}'  to  support  tactical  decision-making.  In 
deciding  whether  or  not  to  board  a  vessel,  timely  access  to  information  such  as 
prior  boardings  or  violations  is  essential  to  improving  law  enforcement. 

...  Many  of  the  Coast  Guard's  information  systems  were  developed  to  support 
narrow  program  needs.  Most  systems  are  not  integrated  and  cannot  share 
information  with  other  existing  Coast  Guard  systems....  field  offices  sometimes  have 
to  use  several  different  systems  to  obtain  information  on  the  variety  of  interrelated 
tasks  they  are  performing.  (GAO/IMTEC-90-32,  April  1990,  pp  2-4). 

This  lack  of  cross-functionality  is  especially  critical  at  field  units:  although  one 
mission  is  usually  primary',  two  or  three  other  missions  are  also  performed  frequently. 
Consequently,  information  from  separate  systems  is  necessary  to  do  a  job  well. 

As  an  example,  consider  the  Group  operations  center  controller  who  gets  a  report 
of  an  overdue  vessel.  These  reports  are  received  frequently  by  the  Coast  Guard,  and  are 
characterized  by  very  sketchy  information  and  high  levels  of  concern.  Rarely  does  the 
Coast  Guard  get  a  good  description  of  the  missing  boat,  its  operator,  or  the  operator's 
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habits  and  plans.  Most  of  these  reports  are  made  in  the  evening  —  a  typical  voyage, 
especially  by  a  recreational  boat,  is  most  likely  to  end  in  the  afternoon,  and  the  report  is 
made  when  boat  is  a  couple  of  hours  late. 

In  this  situation,  what  an  operations  coordinator  needs  most  of  all  is  information. 
First,  a  good  description  is  vital,  because  the  boat  must  be  described  to  all  who  may  have 
seen  it,  such  as  marina  operators,  other  boaters,  or  other  agencies.  Second,  reporting 
sources  often  don't  even  know  who  owns  the  boat;  if  that  information  is  available,  a 
phone  call  to  the  owner  or  another  related  party  may  find  that  there  was  a  change  of 
plans,  or  that  the  missing  party  is  safe  in  another  port.  Finally,  LEIS  contains  records  of 
all  vessels  sighted  by  Coast  Guard  units  on  patrol,  and  a  check  of  that  system  may  yield 
a  sighting  of  the  boat,  which  can  narrow  down  the  search  area  tremendously. 

This  information  is  quite  likely  to  be  in  one  or  another  of  the  systems  considered 
in  this  thesis.  However,  getting  it  is  quite  difficult.  SARMIS  does  not  allow  local  access 
to  its  data  at  all.  SIMS/ELT  does  create  a  local  database  of  reports  by  the  individual  unit; 
however,  it  doesn't  contain  information  from  the  neighboring  station  that  may  help.  LEIS 
contains  information  reported  by  all  units  in  the  Coast  Guard,  but  access  was  recently 
provided  to  Group  offices  (it  had  previously  been  restricted  to  districts  and  above,  for 
security  and  access  reasons).  Finally,  MSIS  contains  vital  ownership  information  on  any 
commercial  or  documented  vessel,  but  almost  no  Group  offices  have  access  to  that 
system.  Even  if  the  operations  center  coordinator  had  access  to  these  systems,  getting  the 
desired  information  is  difficult  because  of  complicated  query  procedures  that  are  different 
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in  each.  A  single,  cross-functional  system  with  a  friendly  user  interface  would  surely  be 
a  boon. 

Chapter  FV  will  examine  current  views  on  the  tradeoffs  involved  in  implementing 
cross-functional  information  systems.  Chapter  V  will  apply  this  material  to  Coast 
Guard's  IRM  situation. 


E.  FUTURE  SYSTEMS  DEVELOPMENT  PATH 

The  Office  of  Command,  Control  and  Communications  (G-T)  at  Coast  Guard 
Headquarters  is  committed  to  ensuring  that  the  Coast  Guard  develops  systems  which  are 
increasingly  cross-functional,  and  rely  on  open  systems  technology  (USCG  COMDTINST 
5230.41,  Aug  31  1990).  Future  systems  development  could  take  any  of  several  paths, 
including  the  following  (listed  roughly  in  order  of  increasing  difficulty  and  cost): 


•  Continue  routine  life  cycle  maintenance  and  upgrades,  but  expend  no  effort  toward 
integrating  systems.  Leave  the  data  structures  as  they  are,  primarily  file  processing 
based. 

•  Develop  common  user  interfaces,  so  that  each  system  looks  and  feels  somewhat 
familiar  to  an  operator  who  has  previously  used  another  system.  However,  make 
no  other  fundamental  changes. 

•  Develop  a  query  interface  that  can  extract  data  from  any  of  the  different  underlying 
systems  while  presenting  only  a  single  interface  to  the  user. 

•  Employ  database  management  systems,  and  develop  similar  architectures,  data 
structures  and  data  dictionaries  for  the  various  information  systems  to  allow  easier 
connectivity. 

•  Develop  a  completely  integrated  information  system  to  replace  the  existing  ones, 
scrapping  the  old  systems  entirely. 
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The  first  path,  the  status  quo,  has  been  criticized  within  the  Coast  Guard  and  by  the 
GAO;  it  is  well  recognized  that  greater  connectivity  and  cross-functionality  are  required. 
The  degree  to  which  those  goals  should  be  pursued,  and  the  rapidity  with  which  we 
pursue  them,  are  the  tough  questions.  Some  work  is  already  in  progress: 


•  The  Corporate  Database  Project  is  a  Decision  Support  System  (DSS)  whose 
database  management  system  extracts  data  from  several  existing  CG  IS's,  aggregates 
it,  and  provides  a  user  with  analytical  models  and  a  graphical  user  interface  to  allow 
sophisticated  interactive  manipulation  of  information  for  programming  and  budget 
decisions  (Synetics  Corp,  1990,  p.  1). 

•  Tlie  Office  of  Command,  Control  and  Communications  (G-T)  has  structured  the 
CG  Standard  Workstation  contract  so  as  to  encourage  use  of  either  Oracle™  or 
Progress™  as  the  DBMS,  in  order  to  establish  a  compatibility  baseline. 

•  Policy  requires  that  all  new  systems  maximize  implementation  of  open  system 
architectures,  in  order  to  allow  for  the  most  flexible  possible  upgrade  paths  and  to 
enhance  competition. 

•  A  set  of  Data  Element  Naming  Conventions  have  been  developed,  for  improving 
compatibility  between  data  dictionaries. 

•  Unisys  Corporation,  the  Coast  Guard  Standard  Workstation  vendor,  is  implementing 
a  two-pronged  approach  to  incorporating  a  Graphical  User  Interface  into  BTOS 
application.  First,  it  will  support  Microsoft's  Presentation  Manager™.  Second,  it 
has  specified  XVT™  (Extensible  Virtual  Terminal)  as  the  API  (Application 
Programming  Interface)  for  BTOS  applications.  The  resulting  similarity  between 
interfaces,  along  with  increased  ease  of  use,  should  make  information  much  more 
accessible. 


F.  RESEARCH  FOCUS 

The  primary'  purpose  of  this  thesis  is  to  suggest  three  ways  in  which  the  Coast 
Guard  can  improve  its  collection  and  use  of  information.  First,  where  possible,  it  should 
improve  the  existing  independent,  functionally  oriented  (stovepipe)  systems.  Second,  it 
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should  aggressively  develop  cross -functional  (or  integrated)  information  systems.  Third, 
and  in  close  coordination  with  the  second,  it  should  develop  a  robust  information 
architecture.  This  will  be  vitally  important  to  all  future  systems  development,  whether 
the  systems  support  a  single  function  or  are  cross-  functional. 

The  thesis  begins  with  an  overview  of  existing  Coast  Guard  information  systems, 
and  recommendation  for  improving  their  standalone  functionality. 

The  research  then  turns  to  the  subject  of  cross-functionality.  A  theoretical 
foundation  for  the  concept  of  cross-functionality  is  laid,  founded  in  organizational 
structure,  and  the  capability  of  information  systems  to  support  existing  and  new  structures. 
These  principles  are  then  applied  to  the  Coast  Guard's  missions,  organization,  and 
information  systems.  A  proposal  for  a  cross-functional  Operations  Information  System 
(OIS)  is  made,  and  some  thought  is  devoted  to  means  of  motivating  such  a  system  in  a 
competitive  budget  climate  such  as  the  one  in  which  Coast  Guard  program  managers  find 
themselves. 
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n.  OVERVIEW  OF  COAST  GUARD  INFORMATION  MANAGEMENT 


This  chapter  presents  a  summary  of  present  Coast  Guard  Information  Resource 
Management  (IRM)  jjolicy;  a  brief  analysis  of  the  recent  past  IRM  policy  atmosphere;  an 
overview  of  the  data  communications  schemes  which  support  Coast  Guard  IRM;  and  a 
description  of  the  Coast  Guard  Standard  Workstation,  which  serves  as  the  data  entry 
terminal  for  nearly  all  of  the  Coast  Guard's  information  systems. 

A.  TOP-LEVEL  GOALS,  POLICIES,  AND  OBJECTIVES 

The  highest  level  policy  statement  on  IRM  is  found  in  Commandant  Instruction 
16000.21,  the  Strategic  Agenda  of  Coast  Guard  Commandant  Admiral  J.W.  Kime.  In  this 
document,  he  states  his  desired  emphasis  for  the  Coast  Guard's  four  primary  operational 
roles  (see  section  I.A.),  as  well  as  for  two  important  support  areas,  (1)  personnel  support, 
and  (2)  information,  facility,  and  hardware  management.  His  IRM-related  goals  are: 

•  Project  future  needs  for  equipment,  capital  and  real  property,  and  assess  the 
condition,  life  expiectancy  and  utility  of  inventory  to  meet  current  and  future 
requirements, 

•  Maintain  a  capital  asset  projection  plan  to  meet  current  and  projected  needs,  and 

•  Increase  efficiency  and  enhance  capability  through  Information  Resource 
Management. 
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The  IRM-related  policies  in  support  of  these  goals  are: 

•  Continually  survey  new  technologies  and  applications  of  technology  which  would 
improve  the  Coast  Guard's  efficiency  or  effectiveness, 

•  Upgrade  facilities  and  equipment  as  roles  change,  new  technologies  are  employed, 
or  obsolescence  is  identified,  and 

•  Acquire  standardized  equipment  which  improves  interoperability  with  other  agencies 
and  is  fully  supportable  within  Coast  Guard  or  other  federal  government  resources 
(COMDTINST  16000.21,  21  Sep  90). 

Primary  Coast  Guard  IRM  policy  in  support  of  the  Commandant's  Strategic  Agenda 
is  contained  in  two  documents:  Commandant  Instruction  (COMDTINST)  5230.41,  and 
COMDTINST  5230.38. 

COMDTINST  5230.38,  Designated  Senior  Official  (DSO)  for  Information  Resource 

Management  (IRM),  begins  by  defining  IRM: 

IRM  was  officially  introduced  into  the  Federal  Government  by  the  Paperwork 
Reduction  Act  of  1980.  This  Act  defines  IRM  as  "...the  planning,  organizing, 
directing,  training,  promoting,  controlling,  and  management  activities  associated 
with  the  burden,  collection,  creation,  use  and  dissemination  of  information  by 
agencies,  and  includes  the  management  of  information  and  related  resources  such 
as  automatic  data  processing  equipment.:  To  emphasize  the  importance  of  IRM  in 
the  Government,  this  Act  requires  the  Senior  Official  in  each  agency  to  designate 
a  DSO  for  IRM.  (COMDTINST  5230.38,  30  May  90). 

The  instruction  then  appoints  the  Chief,  Office  of  Command,  Control,  and 

Communications  (staff  symbol  and  common  shorthand  reference:  G-T),  a  Rear  Admiral, 

as  the  Coast  Guard's  DSO  for  IRM.  His  responsibilities  are  described  in  broad  terms. 


Further  policy  guidance  is  found  in  COMDTINST  5230.41,  Information  Resource 
Management.  It  recognizes  the  state  of  the  existing  suite  of  systems,  then  looks  to  the 
future: 

Most  of  our  existing  information  systems  were  developed  to  meet  individual 
program  needs.  This  approach,  while  reasonable  at  the  time,  has  led  to  many 
current  management  and  information  system  problems,  including  those  of 
conflicting,  erroneous,  and  redundant  data,  and  gaps  between  program-specific 
systems.  The  Coast  Guard  is  fortunate  because  it  now  has  a  widely-developed 
infrastructure  of  standard  information  technology*,  and  this  infrastructure  is 
becoming  more  capable  and  better  intercoimected  every  day.  It  is  now  practical  to 
use  this  infrastructure  for  developing  cross-program  or  cross-functional  information 
systems  to  enhance  our  mission  effectiveness. 

...  A  CFS  (Cross  Functional  System]  is  an  information  system  that  supports 
organizational  processes  relating  the  activities  of  several  programs  or  functional 
divisions,  rather  than  the  activities  of  a  single  program.  (COMDTINST  5230.41,  30 
May  90). 

Of  special  note  in  this  instruction  are  several  IRM  Principles: 

The  following  principles  shall  guide  Coast  Guard  IRM.  They  establish  the 
relationships  between  the  IRM  oversight  and  support  roles  of  Commandant  (G-T) 
and  the  direct  IRM  responsibilities  of  our  major  programs: 

a.  IRM  activities  which  support  improving  the  way  of  doing  business  are 
preferred  to  those  which  simply  automate  or  replace  existing  functions. 

b.  Individual  IRM  solutions  may  be  suboptimized  for  the  greater  good  of  the 
Coast  Guard." 


’This  standard  technology  (the  CG  Standard  Workstation)  is  not  always  implemented  in  a 
standard  fashion,  however.  This  results  in  a  good  set  of  tools,  but  not  quite  yet  a  solid 
infrastructure.  (Squires,  1991). 

^This  deceptively  simple  statement  is  arguably  the  most  important  and  most  difficult  to 
achieve  IRM  policy.  See  chapter  VI  for  a  further  consideration  of  the  issues  involved. 
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...  d.  All  Coast  Guard  locations  will  be  interconnected  with  integrated 
telecommunications  facilities. 

e.  Major  organizational  elements  shall  have  direct  IRM  responsibilities. 

f.  Commandant  (G-T)  has  the  dual  roles  of  Coast  Guard  IRM  oversight  and  C3I 
infrastructure  support. 

...  i.  The  Coast  Guard  will  minimize  data  redundancy  and  multiple  data  entry 
activities.  The  ultimate  goal  is  single  point  data  entry.  (COMDTINST  5230.41, 

30  May  90). 

Finally,  this  instruction  presents  a  rationale  for  implementing  cross-functional 
systems,  in  a  Coast  Guard  context.  This  will  be  expanded  upon  in  Chapter  FV,  which 
discusses  recent  work  in  the  field  of  organizational  design  and  the  increasingly  critical 
role  of  information  systems  as  a  cornerstone  of  the  successful  organization. 

B.  RECENT  PAST  IRM  POLICY  ATMOSPHERE 

The  Coast  Guard  has  not  viewed  information  systems  as  a  strategic  tool  for 
changing  the  way  of  doing  business.  In  large  part,  the  systems  now  in  place  serve  simply 
to  gather  data,  and  perhaps  do  so  in  a  slightly  more  efficient  way  than  the  paper-based 
systems  they  replaced.  However,  they  are  all  independent  systems,  with  no  interaction 
between  each  other,  and  there  is  huge  data  redundancy.  The  data  redundancy  costs  the 
Coast  Guard  significantly,  in  several  ways: 

•  In  wasted  time  by  field  unit  personnel  who  have  to  enter  the  same  data  into  several 
independent  systems,  manually  re-keying  the  data  each  time. 

•  In  storage  and  operations  costs,  since  the  data  are  maintained  at  several  different 
sites  around  the  country,  each  with  dedicated  personnel  and  equipment. 

•  In  data  inconsistencies  which  result  from  the  separately  maintained  databases. 
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Not  all  the  existing  systems  collect  their  data  more  efficiently  than  the  older  systems 
they  replaced.  In  the  case  of  SARMIS,  the  computer-based  system  is  widely  felt  by  field 
personnel  to  require  two  or  three  times  as  long,  per  typical  case,  as  the  paper-based 
system  it  replaced  (somewhat  more  data  is  collected,  but  not  enough  to  account  for  all 
the  difference.  The  awkward  user  interface  is  a  major  contributor  to  the  problem.) 

This  situation  has  prevailed  until  recently,  mainly  for  two  reasons.  First,  past 
information  systems  have  been  developed  primarily  by  program  managers,  with  little 
involvement  fi’om  the  IS  professionals  in  the  Coast  Guard’s  IRM  division,  G-TTC. 
(Decentralization  advocates  would  argue  that  this  is  the  best  way  to  develop  systems,  and 
for  most  application  systems,  that  is  probably  true.  However,  see  Chapter  VI  for  a 
discussion  of  two  special  cases:  cross-functional  systems  and  an  organization-wide 
information  architecture.) 

Second,  G-TTC  does  not  have  sufficient  authority  (and  is  not  in  an  organizational 
position)  to  oversee  information  systems  initiatives.  Accordingly,  each  has  been 
developed  from  scratch  by  a  different  team  acting  without  benefit  of  lessons  learned  from 
other  projects  and  with  little  motivation  to  benefit  the  organization  as  a  whole.  To  be 
fair,  some  program  managers  accuse  G-TTC  of  not  being  responsive  when  approached 
about  becoming  involved  in  developing  a  new  system.  Regardless  of  the  source  of  the 
problem,  there  remains  the  fact  that  not  enough  coordination  has  existed  between  the  IRM 
overseer  and  the  development  staffs. 

Fortunately,  it  seems  that  this  may  change.  Program  managers  see  the  benefits  of 
integrated  systems  and  parallel  systems  development,  and  are  cooperating  much  more 
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closely  in  the  generation  of  systems  which  arc  now  in  the  planning  stages.  Top 
management  has  begun  to  give  G-TTC  more  authority  over  systems  development,  partly 
by  designating  G-T  as  the  "Designated  Senior  Official"  for  IRM. 

C.  DATA  COMMUNICATION  IN  SUPPORT  OF  IRM 

Almost  all  data  entry  for  the  information  systems  considered  in  this  thesis  is  done 
on  the  standard  workstation,  then  transmitted  to  the  central  database  by  one  of  several 
means.  This  section  first  describes  the  various  data  communications  networks  in  use  by 
the  Coast  Guard,  then  delineates  the  ways  in  which  systems  use  them. 

1.  Coast  Guard  Data  Communication  Networks 

a.  AUTODIN: 

For  record  message  traffic  between  the  major  nodes  of  its  communication 
system,  the  Coast  Guard  uses  the  Department  of  Defense's  Automatic  Digital  Network. 
Major  Coast  Guard  communication  centers  (CGHQ,  Areas,  Districts,  and  CommStas,  etc.) 
have  AUTODIN  drops,  where  they  interface  between  this  long-haul  network  and  the 
other  networks  described  below. 

b.  SSAMPS  and  SW/SSAMPS 

Since  the  Coast  Guard  has  AUTODIN  drops  at  only  a  few  major  nodes, 
the  Coast  Guard  has  built  its  own  networks  for  relaying  record  messages  to  smaller  units. 
The  networks  that  perform  this  job  are  called  DlSTNETs  (below).  The  interface  between 
AUTODIN  and  the  DlSTNETs  is  the  Standard  Semi-Automated  Message  Processing 
System  (SSAMPS).  Earlier  versions  of  SSAMPS  used  special-purpose  Hewlett-Packard 
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hardware  at  major  nodes.  A  shift  is  underway  to  replace  this  hardware  with  general- 
purpose  CG  Standard  Workstations  (CGSW),  giving  rise  to  the  new  name  SW/SSAMPS. 
This  system  is  installed  at  the  major  nodes  where  AUTOIDIN  drops  are  located,  and 
interfaces  between  the  Coast  Guard  and  DOD  networks. 

c.  DISTNET 

The  District  Telecommunications  Networks  are  distribution  networks  for 
record  messages,  used  within  a  single  district,  and  connected  to  SSAMPS.  These 
networks  are  being  converted  from  supporting  record  messages  only  to  supporting  general 
data  transfer.  Also,  they  are  being  converted  from  dedicated  landlines  to  the  new  Hybrid 
Data  Network  (see  below). 

d.  HDN 

The  Hybrid  Data  Network  is  a  new  system  that  will  connect  shore  units. 
It  will  replace  and  consolidate  several  transmission  services,  including  record  messages, 
the  independent  network  which  supported  MSIS,  and  several  others.  The  HDN  will  allow 
three  access  methods  for  data  transmission,  providing  flexible  support  to  systems: 


•  Dedicated  X.25  service:  dedicated,  leased  packet  switched  lines,  4800  to  9600  bps. 
Terminal  equipment  is  on-line  at  all  times. 

•  Virtual  Dedicated  X.25  service:  leased  packet  switched  lines,  2400  bps.  Terminal 
equipment  appears  on-line  to  the  user,  but  is  actually  connected  to  a  switched  voice 
grade  line  when  a  connection  is  needed,  and  disconnected  at  other  times.  The 
network  is  able  to  "call"  dedicated  and  virtual  dedicated  users. 

•  Asynchronous  dial  access:  users  must  dial  the  network  themselves;  the  function  is 
not  automatic,  as  with  virtual  dedicated  service. 
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These  access  methods  obviously  have  important  effects  on  the  systems. 
The  first  is  appearance  to  the  user:  if  there  is  dedicated  or  virtual  dedicated  access,  the 
user  feels  as  if  the  system  is  right  there,  since  he  or  she  does  not  have  to  worry  about 
establishing  the  coimection  to  the  remote  site.  With  dial-up  access,  on  the  other  hand, 
the  user  has  in  the  past  seen  the  separation  between  local  and  remote  systems  clearly  (and 
perhaps  painfully),  since  establishing  the  connection  has  been  done  manually.  The  dial¬ 
up  function  is  now  being  built  into  application  systems  by  their  developers.  These 
systems  rely  on  dial-up  access  from  low-volume  users,  but  automate  the  connectivity 
task  for  them  after  a  one-time  setup  by  the  local  system  operator. 

The  second  effect  is  timeliness.  All  three  methods  allow  on-line  updating 
and  interactive  querying  of  the  host.  However,  the  rapidity  of  on-line  updates  may  not 
be  necessary  for  some  systems;  it  will  be  cheaper  to  save  data  until  off-peak  hours,  and 
then  transmit  them  in  a  batch. 

e.  SprintNet 

This  network,  formerly  called  TeleNet,  is  operated  by  U.S.  Sprint,  and 
the  Coast  Guard  (through  an  FAA  contract)  purchases  data  transmission  services  on  it  for 
the  HDN  (above).  When  the  present  contract  expires  on  June  8,  1992,  it  will  not  be 
renewed;  rather,  services  will  be  purchased  from  other  carriers  under  the  terms  of  GSA's 
new  FTS2000  communications  contract.  Some  hardware  at  Coast  Guard  sites  is  presently 
leased  from  Sprint  along  with  the  lines;  this  will  be  replaced  with  Coast  Guard-owned 
equipment  before  the  cutover  date. 
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/.  Electronic  Mail 

The  standard  workstation  supports  electronic  mail  using  Unisys’  B-Mail 
program.  Each  LAN  constitutes  a  "mail  center"  (the  exact  configuration  may  vary 
somewhat),  which  is  analogous  to  a  post  office.  Large  units  with  several  LANs  may  have 
only  a  single  mail  center  (a  "capital"  center)  that  serves  all  internal  LANs.  Messages  can 
be  sent  to  and  from  any  user  at  any  center,  and  any  form  of  binary  file  can  be  "attached," 
allowing  easy  exchange  of  computer  files.  This  system  can  also  be  used  for  record 
messages  —  SW/SSAMPS  uses  B-Mail  as  its  transport  mechanism.  One  drawback  is 
that  the  system  requires  intensive  involvement  by  local  system  administrators. 

g.  ITDS 

The  Information  Transfer  and  Delivery  System  replaces  the  Message 
Transfer  and  Delivery  System  (MTDS),  and  integrates  transmission  of  data  and  record 
messages  between  districts.  It  uses  B-mail  and  the  HDN. 

2.  Information  System  Use  of  Networks 
a.  SARMIS 

Until  1990,  field  units  sent  paper  reports  from  SARMIS/DES  (the  Data 
Entry  Subsystem)  to  their  district  offices,  where  they  were  keypunched  by  a  DP  staff  into 
80-column  card  images.  District  staff  members  then  performed  manual  data  checking 
and  validation.  Validated  records  were  transmitted  to  the  SAR  database  at  headquarters 
by  Remote  Job  Entry  (RJE). 
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A  recent  upgrade,  SARMIS/DES  version  1.2,  allows  field  units  to  send 
their  data  to  the  district  by  mailing  floppy  disks,  or  as  attachments  to  electronic  mail 
messages.  There,  district  staffs  enter  data  into  SARMIS/DSS,  the  District  Sub- System. 
Transfer  from  districts  to  the  SAR  database  will  continue  to  be  done  via  RJE,  but  will 
use  the  HDN  as  the  transfer  network  when  its  RJE  capability  is  functional. 

b.  SIMSIELT  and  LEIS 

The  original  input  mechanism  for  LEIS  was  SEER  messages,  manually 
prepared  by  field  units  and  sent  via  SSAMPS  and  AUTODIN  to  the  OCC  in  New  York, 
where  they  were  electronically  scanned,  checked,  and  entered  in  the  database  if  valid. 
SIMS/ELT  will  prepare  and  send  these  messages  automatically,  and  print  a  local  copy  of 
the  message  report.  Alternately,  the  program  can  generate  a  report  to  be  sent  as  an  E- 
mail  attachment  (however,  this  mode  is  not  yet  suported  at  the  OCC,  so  is  not  yet 
implementable).  Data  are  transmitted  directly  to  the  central  database,  and  are  usually  on¬ 
line  within  24  to  48  hours. 

c.  MSIS 

MSIS  data  are  entered  on-line  by  field  users,  in  interactive  sessions.  The 
system  has  in  the  past  used  its  own  system  of  X.25  packet-switched  lines,  leased  from 
SprintNet,  but  is  transitioning  to  the  Hybrid  Data  Network.  Data  arc  available  to  other 
users  immediately  after  it  they  are  entered. 


D.  COAST  GUARD  STANDARD  WORKSTATION 


In  the  early  1980's,  when  there  was  no  clear  choice  of  microcomputer  and  op)erating 
system^,  the  Coast  Guard  conducted  a  competitive  procurement  for  a  general  purpose 
microcomputer  contract.  This  procurement  promoted  standardization,  prevented  a 
proliferation  of  incompatible  equipment,  and  was  intended  to  provide  the  service  with 
state  of  the  art  microcomputer  capabilities,  which  could  be  readily  expanded.  (Maes, 
1987,  p.  3). 

1.  Hardware 

The  hardware  contract  for  the  Coast  Guard  Standard  Terminal,  now  called  the 
Coast  Guard  Standard  Workstation  (CGSW),  was  originally  awarded  in  June  1981  to  C3, 
Incorporated,  and  called  for  fixed  unit  prices  on  equipment  to  be  supplied  in  variable 
quantities,  as  commands  needed  the  machine  (Maes,  1987,  p.  42).  That  contract  was 
renewed  several  times,  then  recompeted  and  awarded  to  Unisys  Corporation,  which  is 
presently  the  vendor  for  the  CGSW. 

The  machines  purchased  under  the  original  contract  and  subsequent  renewals 
are  similar  to  the  IBM  PC  and  its  progeny  in  that  they  are  based  on  the  Intel  80x86 
microprocessor  series.  However,  the  operating  system,  Unisys'  BTOS  (formerly  CTOS), 
is  different  (see  below).  The  growth  in  capabilities  and  numbers  of  personal  computers 
at  Coast  Guard  units  has  been  similar  to  that  in  the  rest  of  the  business  world.  The 
CGSW  has  become  an  integral  part  of  information  use  at  every  unit. 

■’The  dominant  microcomputer  operating  system  was  CP/M,  the  IBM  PC  had  not  been 
introduced,  and  Apple  was  little-known. 
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2.  Operating  System 


The  Convergent  Technologies  Operating  System  (CTOS)  was  capable  of 
networking,  unlike  other  microcomputer  architectures.  The  only  technology  for  shared 
computing  resources  available  at  the  time  was  minicomputers  or  mainframes  with  multiple 
dumb  terminals.  C3  was  at  that  time  unique  in  offering  the  ability  to  network  smart 
terminals  and  share  system  services  without  the  overhead  of  a  minicomputer. 

The  operating  system  is  based  on  a  command  language  interface,  similar  to 
those  in  PC-DOS  and  basic  Unix,  with  one  exception:  the  user  types  in  the  command 
name,  or  any  unique  abbreviation  thereof,  presses  <Retum>,  and  is  then  pres  d  with 
a  fill-in  form  listing  all  possible  parameters  for  that  command,  and  indications  of  whether 
each  parameter  is  required  or  optional.  This  is  in  contrast  to  DOS  and  Unix,  wherein  the 
user  must  type  the  command  name  and  all  parameters  at  once,  and  gets  no  prompting 
about  parameters.  The  CTOS  <Help>  facility  should  be  more  meaningful,  but  for 
experienced  users,  like  most  system  administrators  are,  this  interface  is  very  quick  and 
easy  to  use. 

3.  User  Interface 

From  a  user  interface  point  of  view,  the  CGSW  keyboard  is  significantly 
different  from  that  of  the  IBM  PC;  there  are  dedicated  keys  for  <Help>,  <Finish>-ing 
applications,  <Mark>-ing  and  <Bound>-ing  text  to  be  manipulated,  and  for  scrolling  text 
onscreen  without  changing  the  cursor's  relative  position.  Dedicating  and  clearly  labeling 
these  keys  makes  it  much  easier  for  neophytes  to  learn  applications,  and  for  experienced 
users  to  use  them,  if  the  application  software  supports  them  well.  For  instance,  if  a  user 


sees  a  key  labelled  <Help>,  presses  it,  and  gets  a  meaningful  explanation  of  possible 
actions  in  the  present  context,  then  it  has  been  successful.  If  the  message  is  a  general  one 
and  laden  with  computer  jargon,  then  it  fails  to  give  the  user  the  desired  assistance. 

Just  as  in  the  DOS  world,  CTOS/BTOS  application  software  has  had  no 
standard  interface  until  recently,  when  a  small  amount  of  standardization  has  been 
achieved.  Most  CGSW  applications  now  display  "softkeys",  or  labels  that  apply  to  the 
ten  function  keys,  across  the  bottom  of  the  screen,  either  continually  or  on  demand.  In 
some  applications,  such  as  B-Mail  and  SIMS/ELT,  these  very  effectively  take  the  place 
of  a  menu,  changing  their  meanings  as  different  actions  are  taken. 
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III.  EXISTING  USCG  OPERATIONAL  INFORMATION  SYSTEMS 


This  chapter  presents  a  picture  of  the  state  of  Coast  Guard  information  management 
by  examining  three  existing  operational  information  systems.  The  systems  being 
considered  were  selected  because  they  are  used  by  a  large  proportion  of  Coast  Guard 
units.  Also,  they  represent  a  large  part  of  the  spectrum  of  decision  types,  supponing  both 
tactical  and  strategic  decisions.  Sections  A  through  C  of  this  chapter  describe  in  some 
detail  the  systems  that  support  the  Marine  Safety,  Law  Enforcement,  and  Seeirch  and 
Rescue  programs.  Section  D  briefly  describes  some  others,  to  lend  the  reau  r  a  sense  of 
thf  scope  of  Coast  Guard  information  and  the  present  attempts  to  manage  it. 

A.  MARINE  SAFETY  SYSTEMS 

The  Marine  Safety  Information  System  (MSIS)  supports  the  headquarters  office  of 
Marine  Safety,  Security,  and  Environmental  Protection  (G-M).  A  replacement  system, 
the  Marine  Safety  Network  (MSN),  is  in  the  planning  stages. 

I.  System  Background  and  Goals 

In  1974,  the  office  of  Merchant  Marine  Safety  developed  the  Vessel  Inspection 
Information  System  (VIIS).  In  1977,  the  Office  of  Marine  Environment  and  Systems 
developed  the  Port  Safety  Reporting  System  (PSRS),  for  tracking  violation  histories  of 
vessels  calling  at  U.S.  ports.  In  1984,  the  two  were  combined  to  form  the  Marine  Safety 
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Information  System.  A  Vessel  Documentation  module  was  added  to  the  system  in  1988. 
(COMDTINST  M5230.il A,  p.  1). 


The  Marine  Safety  program  has  several  responsibilities,  including:  inspection 
of  vessels  and  facilities,  documentation  of  vessels,  licensing  of  maritime  personnel,  eind 
protection  of  the  marine  environment.  These  are  carried  out  by  roughly  110  field  units, 
including  Marine  Safety  Offices  (MSO's),  Marine  Inspection  Offices  (MIO's),  Regional 
Examination  Centers  (RECs),  and  others.  Because  the  vessels  and  people  being  regulated 
are  highly  mobile,  a  central  clearinghouse  for  information  about  them  is  vital.  MSIS 
serves  as  that  central  clearinghouse  —  an  interactive  central  database  that  is  updated 
frequently  by  field  units. 

MSIS-supported  decisions  are  both  tactical  ("should  I  inspect  vessel  XYZ 
when  it  enters  port  today?")  and  strategic  (should  the  Coast  Guard  issue  new  tanker  safety 
regulation  AB1234?").  A  secondary  goal  is  to  automate  certain  processes,  as  a  time-  and 
labor-saving  tool. 

After  more  than  a  decade  of  evolution,  MSIS  is  more  thoroughly  integrated 
into  the  daily  routine  of  marine  safety  personnel  than  any  other  operational  information 
system  in  the  Coast  Guard.  It  serves  as  a  source  of  information  and  as  the  primary'  tool 
for  reporting  operations;  it  is  an  effective  means  of  sharing  information  about  vessels 
between  the  many  MSO's.  This  is  not  to  say  that  it  is  completely  well  integrated;  on  the 
contrary,  users  still  complain  about  some  facets  of  the  system.  However,  marine  safety 
units  could  no  longer  perform  their  mission  without  MSIS,  and  it  is  the  most  heavily 
relied-upon  operational  system  in  use  in  the  Coast  Guard  today. 
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2.  User  Interface 


MSIS  is  menu-driven,  making  it  easy  for  users  to  learn  and  use.  One 
shortcoming  of  the  existing  system  is  that  the  entire  screen  display,  menus  and  all,  is  sent 
over  the  telecommunications  link  between  host  and  user.  This  means  that  it  can  take 
several  seconds  to  completely  refresh  a  screen  display,  slowing  the  session  down 
significantly.  Also,  the  menu  structure  is  organized  with  respect  to  the  information 
products  stored  in  the  data  tables,  rather  than  by  function  or  purpose.  This  means  that 
users  must  be  familiar  with  the  structure  of  the  database  in  order  to  retrieve  information 
from  it.  (Wilder,  1991). 

3.  Hardware,  Software,  and  Telecommunications 

Field  units  use  CGSW's  and  modems  to  link  with  the  host.  The  CGSW's 
employ  no  processor  power  in  the  present  system,  but  act  as  dumb  terminals.  The  host 
is  a  network  of  Prime  minicomputers  at  Batelle  Labs,  Columbus,  Ohio.  Batelle  created 
the  Automated  Construction  of  Transaction  Systems  (ACTS),  a  rudimentary  4GL,  to 
generate  FORTRAN  code  for  the  application  programs,  and  relics  on  Total,  a  relational 
DBMS,  for  the  data  base.  (USCG  Agency  Procurement  Request,  1991). 

4.  Future  development  plans 

CGHQ  (G-MIM)  is  designing  a  follow-on  to  MSIS,  which  will  be  called  the 
Marine  Safety  Network.  It  will  stress  interaction  with  other  systems,  including  LEIS  II 
and  external  databases.  It  will  be  a  distributed  system,  using  the  processing  power  of 
remote  CGSW's,  and  have  a  graphical  user  interface.  It  will  rely  on  the  Hybrid  Data 
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Network  for  transport.  Hardware  and  software  configurations  are  yet  to  be  determined, 
but  will  be  based  on  open  systems  architecture.  This  will  include  POSIX-compliant 
operating  systems  (Standard  Portable  Operating  System  Interface  for  Computer 
Environments,  FIPS  PUB  151),  GOSIP-compliant  communications  architecture 
(Government  Open  Systems  Interconnection  Profile,  FIPS  PUB  146),  and  SQL- 
compatible  (Structured  Query  Language,  FIPS  PUB  127)  database  management  system. 
(USCG  Agency  Procurement  Request  for  MSN,  1991). 

B.  LAW  ENFORCEMENT  SYSTEMS 

The  headquarters  office  of  Defense  Operations  and  Law  Enforcement,  Law 
Enforcement  Division  (G-OLE),  is  supported  by  a  combination  of  three  systems  described 
below.  A  replacement  system,  the  Law  Enforcement  Information  System  version  II  (LEIS 
II),  is  in  the  development  stage. 

1.  System  Background  and  Goals 

Before  the  mid-1980's,  there  was  no  central  Coast  Guard  database  of  law 
enforcement  information.  Information  was  reported  by  teletype  message  from  operating 
units  to  their  district  commanders,  who  typically  retained  some  sort  of  paper  file. 
Districts  typically  had  different  reporting  requirements,  although  there  was  some 
standardization  within  Atlantic  Area  and  Pacific  Area,  respectively.  When  units  operated 
outside  their  normal  areas,  they  had  to  check  manuals  for  the  different  reporting 
requirements  and  message  formats.  In  the  mid-1980's,  the  Coast  Guard  standardized  law 
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enforcement  reporting  nation-wide.  Operating  units  still  submitted  teletype  messages,  but 
now  they  were  the  same  everywhere. 


The  new  law  enforcement  message  system  iss  the  Summary  Enforcement  Event 
Reporting  System  (SEER).  The  messages  are  computer-formatted,  with  strictly  defined 
fields.  The  fields  make  up  "Event  Lines,"  each  of  which  becomes  a  database  record. 

The  SEER  messages  are  sent  to  operational  commanders,  and  also  to  the 
Operations  Computer  Center  in  New  York,  where  they  are  stored.  The  Law  Enforcement 
Information  System  (LEIS)  was  then  designed  to  allow  program  managers  to  retrieve 
information  via  modem  connection  from  CGSW's. 

Finally,  in  1988,  the  Shipboard  Information  System/Enforcement  of  laws  and 
Treaties  (SIMS/ELT)  was  introduced.  It  automates  the  preparation  of  SEER  messages, 
and  creates  a  local  database  for  the  field  unit’s  use.  SIMS/ELT  does  not  allow  direct 
interaction  or  online  updating  of  the  LEIS  database;  it  is  strictly  an  input  system.  Input 
messages  arrive  at  the  OCC  and  are  buffered,  manually  checked  for  errors,  and  then 
entered  in  batches.  The  input  data  can  be  available  for  retrieval  in  LEIS  as  soon  as  a  few 
hours  after  the  incident  in  the  best  case,  but  more  typically  between  24  and  48  hours  later. 

The  existing  system  was  designed  mostly  for  strategic  decision  making  by 
program  managers.  It  was  not  accessible  to  field  units  until  April  1991  (COMDT 
COGARD  MSG  011755Z  APR  91),  so  tactical  support  was  not  provided.  One  limited 
exception  is  that  units  were  able  to  gain  some  information  through  voice  radio  requests 
to  group  and  district  offices,  but  this  method  was  cumbersome. 
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2.  User  Interface 


The  LEIS  interface  is  one  of  the  most  difficult  among  existing  Coast  Guard 
systems.  Although  a  few  menus  are  available,  it  consists  primarily  of  a  proprietary 
command  line  query  language.  Like  all  query  languages,  this  one  is  extremely  involved 
for  the  uninitiated.  The  Coast  Guard  operates  week-long  training  sessions  to  indoctrinate 
users  in  LEIS,  and  most  of  the  time  is  spent  on  the  query  language;  however,  because  of 
the  complexity  of  command-line  languages  in  general,  many  still  have  trouble  using  all 
the  capabilities  of  the  system  after  completion  of  the  school.  LEIS  supports  information 
retrieval  only;  no  on-line  updating  is  allowed,  since  all  input  is  via  SEER  or  SIMS/ELT. 

The  SIMS/ELT  interface,  in  contrast,  is  probably  the  best  among  present  Coast 
Guard  systems,  and  therefore  will  be  described  in  somewhat  more  detail.  It  is  a  clearly 
organized  form-based  system,  and  keeps  users  aware  of  their  progress  and  the  big  picture 
throughout  a  session.  A  typical  data  entry  screen,  for  an  Identification  Event  Line,  is 
shown  in  Figure  1. 

The  form-based  design  of  SIMS/ELT  allows  rapid  data  entry,  in  contrast  to 
the  SARMIS  interface,  which  will  be  described  in  the  next  section.  On-screen  forms 
consist  of  several  logically  related  data  fields,  and  are  rewritten  only  after  a  complete 
form  is  done,  so  users  can  move  quickly  between  fields.  Finally,  it  has  a  well- 
implemented  on-line  help  function.  A  single  press  of  the  <Help>  key  brings  up  a  box 
that  describes  the  purpose  and  content  of  the  record,  or  Event  Line,  currently  being 
entered,  and  all  fields  within  it.  A  second  press  yields  a  box  with  all  valid  codes  for  the 
present  field. 
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I  Enter  dala  ir>seiect€d:fieM: 


t . »»»  .MentlflcattonL(ne  *** 


Event  ID  Patrol  Nunber  OPFAC 


DateCivW/Domri . 

tSBBBBBBBBt 

Color  Hull:SS  . . . 

Detection  ID . 

BB8& 

Vessel  Name _ 

ThieCZULU.rt-Mln]  .. 

BB 

State  ntirber  . . . 

Vessel  type . 

sm 

Radio  Call  Sign . . 
Official  Doc*... 

Activity  of  Vessel . 

SUSP  iclon  Code . 

B 

Hull  ID* . 

Main  Beam  «  . . . . 

Boarding  Code . 

Length  (Ft  or  Mt) . 

B 

Flag . 

Home  Port . 

Figure  1:  SIMS/ELT  Identification  Event  Line  data  entry  screen. 


The  SEER  and  SIMS/ELT  system  is  based  on  events.  Each  event  type  is 
described  by  a  line  of  data,  and  each  has  a  dedicated  data  capture  screen.  The  nine  event 
types  defined  by  the  system  are: 

•  OPAREA  Employment 

•  Position 

•  Detection 

•  Identification 

•  Boarding 

•  Violation 
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•  Last/Next  Port  of  Call 


•  Crew 

•  Remarks 

This  organization  of  the  reporting  system  into  logical  data  records  based  on 
real-world  occurrences  makes  it  easy  to  understand  and  use. 

3.  Hardware,  Software,  and  Telecommunications 

SIMS/ELT  runs  on  the  CG  Standard  Workstation.  1£1S  runs  on  a  PRIME 
9955  mod  2  minicomputer  at  the  Operations  Computer  Center. 

LEIS  was  written  in  Primeinfo  by  the  Department  of  Transportation's 
Transportation  Systems  Center  (TSC)  in  1985.  It  has  been  modified  extensively  by  Coast 
Guard  personnel  since  its  implementation.  The  hardware  and  software  will  be  moved  to 
the  Operations  Systems  Center  in  Martinsburg,  West  Virginia  when  that  facility  opens  in 
1991. 

SIMS/ELT  was  written  by  the  Coast  Guard's  Electronics  Engineering  Center 
(EECEN),  Wildwood,  NJ.  It  is  written  in  Application  Development  System  (ADS),  a  4th 
generation,  forms-oriented  programming  language,  for  use  on  the  Coast  Guard  Standard 
Workstation.  ADS  includes  DBMS  functionality  for  maintaining  the  local  data  base. 

Data  communications  at  present  are  by  record  message.  SIMS/ELT  supports 
E-mail  transfers,  but  that  option  is  not  available  at  the  OCC  yet.  In  the  former  case, 
SEER  messages  are  transmitted  to  the  OCC  as  AUTODIN  messages;  this  method  usually 
uses  SSAMPS  from  the  unit  to  the  district  office,  then  either  AUTODIN  or  ITDS  to  the 
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OCC.  At  the  OCC,  incoming  SEER  messages  are  scanned  electronically  into  the  batch 
update  queue.  Messages  containing  enors  arc  marked  for  human  intervention.  In  the 
latter  case,  SIMS/ELT  sends  SEER  data  as  B-mail  attachments.  These  are  also  collected 
in  a  batch  queue.  Since  they  are  machine-prepared  at  the  unit  level,  and  SIMS/ELT 
employs  validity  checks,  the  error  rate  is  much  lower  than  for  SEER  messages,  but  a  few 
are  still  rejected. 

4.  Future  development  plans 

The  follow-on  system,  LEIS  II,  has  been  designed,  and  coding  will  begin  in 
mid-1991.  The  system  will  stress  tactical  decision  support,  with  the  goal  of  being 
available  to  field  units  with  quick  response  times  for  board/no-board  decisions.  It  will 
rely  on  a  distributed  architecture,  with  a  central  minicomputer  as  the  server  and  remote 
CGSWs  linked  via  various  telecommunications  channels.  It  will  also  stress  open  systems 
architecture,  compliant  with  GOSIP,  POSIX,  and  SOL.  (System  Resources  Corp., 
8/20/90). 

C.  SEARCH  Also  RESCUE  SYSTEMS 

The  headquarters  office  of  Navigation  Safety  and  Waterway  Management,  Search 
and  Rescue  Division  (G-NRS),  is  supported  by  a  combination  of  three  systems. 
SARMIS/DES  (Data  Entry  Subsystem)  is  used  at  the  unit  level  for  data  entry. 
SARMIS/DSS  (District  Subsystem)  is  used  at  district  offices  for  compiling  a  district-wide 
database  and  to  prepare  data  for  upload  to  the  central  database.  The  SAR  database  is  the 
central,  Coast  Guard-wide  database. 
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1.  System  Background  and  Goals 


For  years,  units  submitted  a  SAR  Assistance  Report  to  CGHQ  for  every  SAR 
case  performed.  The  data  was  compiled  in  the  SAR  database,  and  used  to  justify  budget 
requests  and  for  strategic  resource  plsmning.  Input  remained  in  the  form  of  the  paper 
report,  form  CG-5151,  until  about  1986,  when  SARMIS/DES  was  implemented  to 
automate  the  process  and  expand  the  amount  of  data  collected.  Finally,  in  1989, 
SARMIS/DSS  was  developed,  allowing  district  offices  to  compile  their  own  district-wide 
databases  and  conduct  error-checking  before  forwarding  unit  reports  on  to  headquarters. 

As  mentioned  above,  the  primary*  purpose  of  the  SAR  database  is  strategic 
decision  support.  A  secondary  use  of  the  SAR  database  is  to  provide  density  plots  and 
other  decision  toots  for  district,  group,  and  unit  planners;  however,  this  support  is 
provided  off-line,  requires  a  written  request  via  the  chain  of  command,  and  takes  several 
weeks,  so  usability  is  low. 

SARMIS/DES  was  designed  to  automate  the  data  input  process,  and  eliminate 
keypunching  at  headquarters.  However,  since  it  collects  significantly  more  data  than  the 
old  paper  forms,  users  estimate  that  it  takes  roughly  twice  as  long  to  document  a  case 
using  the  computer  than  it  did  with  paper.  The  program  provides  the  unit  with  a  few 
pre-formatted  monthly  summary  reports,  but  does  not  allow  ad-hoc  queries. 

SARMIS/DSS  runs  on  CGSWs  at  the  district  offices,  accepting  input  in  the 
form  of  data  from  SARMIS/DES.  It  validates  data,  then  uploads  it  to  the  SAR  database 
using  RJE.  It  also  provides  an  interactive  database,  written  in  C  and  Progress,  which  can 
be  used  for  ad-hoc  queries  about  SAR  incidents  within  the  district. 
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2.  User  Interface 


The  interface  for  the  central  SAR  database  is  a  command -line  query  language. 
However,  there  is  no  provision  for  remote  access  to  the  system  by  operating  units.  All 
requests  for  information  are  submitted  to  headquarters  on  paper,  where  a  computer 
operator  issues  the  database  query  and  mails  the  report  back  to  the  requestor. 

SARMIS/DES  is  operated  by  field  unit  personnel,  usually  the  boat  coxswain 
or  a  watchstander  who  was  involved  in  a  particular  case.  It  claims  to  be  interactive,  but 
is  so  only  in  the  data  entry  module.  There  is  no  capability  to  query  the  local  database 
in  an  ad-hoc  fashion.  Units  simply  get  pre-formatted  monthly  summaries  and  electronic 
reports  to  send  to  the  district  office.  SARMIS/DES  typically  asks  the  user  one  question 
per  screen,  then  clears  it  and  rewrites  the  next  question.  This  design  makes  it  easy  to 
learn,  but  very  slow  in  general  use,  since  users  must  continually  refocus  on  the  new 
screen  and  re-orient  themselves  to  the  question  being  asked.  It  also  prevents  the  user 
from  retaining  a  feel  for  progress  through  the  program  —  one  quickly  becomes  lost  in 
the  maze  of  new  screen  displays.  On-line  help  is  limited;  however,  since  each  question 
is  presented  in  such  great  detail  on  the  primar>’  data  entry  screen,  this  is  not  a  terrible 
drawback.  If  a  user  is  forced  to  stop  data  entry  before  a  record  is  complete,  there  is  no 
way  to  save  what  has  been  done  so  far,  a  serious  drawback  when  data  entry  for  each 
record  takes  from  five  to  fifteen  minutes. 

3.  Hardware,  Software,  and  Telecommunications 

The  SAR  database  is  hosted  on  an  Amdahl  mainframe  computer  at  the 
Transportation  Computer  Center,  Washington  DC.  The  Coast  Guard's  access  to  the 
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database  is  through  an  asynchronous  1200  bps  terminal  in  the  offices  of  G-NRS,  where 
a  single  GS-11  employee  performs  maintenance  and  issues  queries.  Ten  years'  data  are 
stored  online;  that  comprises  roughly  700,000  records,  approximately  150  megabytes. 
The  program  was  written  in  the  late  1970's  by  personnel  at  the  Transportation  Systems 
Center  using  Focus™,  a  relational  DBMS. 

SARMIS/DSS  and  SARMIS/DES  both  run  on  the  Coast  Guard  Standard 
Workstation.  SARMIS/DSS  is  written  in  C  and  Progress,  a  fourth-generation  language 
and  DBMS.  It  was  developed  in  1989  by  Ship  Analytics,  Incorporated,  under  contract 
to  the  Coast  Guard  Research  and  Development  Center.  SARMIS/DES  is  written  in 
Pascal.  It  uses  Direct  Access  Method  (DAM)  to  access  the  data,  not  a  DBMS. 

SARMIS/DES  data  can  be  sent  to  the  district  office  by  E-mail,  record 
message,  mailing  floppy  disks,  or  mailing  paper  reports.  From  the  district  office  to 
headquarters,  data  is  sent  over  a  synchronous  9600  bps  line,  using  RJE  (remote  job  entry) 
software. 

G-NRS  will  shift  to  the  Hybrid  Data  Network  in  late  1991,  when  the  BTOS 
version  of  RJE  has  been  modified  to  support  the  X.25  protocol. 

Mailing  paper  reports  and  floppy  disks  from  units  to  the  district  is  becoming 
increasingly  rare,  with  most  units  using  E-mail  and  a  few  using  messages. 

4.  Future  development  plans 

The  SAR  database  has  several  shortcomings.  It  still  uses  only  the  limited  set 
of  data  collected  by  the  paper  forms  CG-5151  before  1986,  not  the  full  range  of 
information  collected  by  SARMIS/DES.  It  is  the  only  application  still  using  FOCUS  at 
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the  DOT  computer  center,  and  there  is  pressure  from  system  operators  there  to  migrate 
to  another  language,  perhaps  Oracle. 

SARMIS/DES  will  be  rewritten  soon  to  move  away  from  Pascal  and  DAM, 
and  into  a  DBMS  that  allows  flexible  queries  locally.  G-NRS  is  cooperating  with  G- 
OLE,  G-OP,  and  the  RDC  to  investigate  a  sortie-based  data  collection  front  end,  which 
will  collect  data  only  once,  then  feed  it  to  the  systems  that  need  it.  It  could  use  the 
Geographic  Display  Operations  Computer  (GDOC)  system  when  that  becomes 
operational. 

D.  OTHER  USCG  INFORMATION  SYSTEMS 

This  section  describes  some  of  the  Coast  Guard's  other  information  systems,  to 
provide  the  reader  a  sense  of  the  scope  of  Coast  Guard  information  management. 

1.  CASP 

Computer-Assisted  Search  Planning,  or  CASP,  is  more  a  computational 
program  for  modelling  and  planning  maritime  searches  than  an  information  system;  the 
data  entered  by  an  operator  are  used  only  as  inputs  for  the  program  to  predict  drift  and 
search  areas,  and  are  normally  not  saved  for  review  by  program  managers.  It  is  an 
interactive,  menu-driven  program  hosted  on  a  PRIME  9955  minicomputer  at  the  OCC. 
It  will  move  to  the  OSC  in  Martinsburg,  WV. 

2.  AMVER 

Automated  Mutual  Assistance  Vessel  Rescue,  or  AMVER,  is  one  of  the  oldest 
systems  in  use  by  the  Coast  Guard.  It  was  developed  in  the  mid-1960's,  pursuant  to 
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international  search  and  rescue  agreements,  in  order  to  track  seagoing  ships.  These  ships 
voluntarily  submit  sail  plans,  which  are  keypunched  into  a  database  in  the  PRIME  9955 
minicomputer  at  the  OCC.  The  system  is  accessed  by  rescue  coordinators  and  search 
planners,  so  that  during  a  distress  at  sea  they  may  quickly  determine  what  vessels  are 
nearby  and  radio  them  directly  for  assistance.  A  follow-on,  AMVER  2,  is  under 
development,  to  provide  better  access  and  output. 

3.  OTHER  SYSTEMS 

There  are  many  more  systems  in  use  or  under  development.  Tables  2  and  3 
show  those  listed  in  the  Coast  Guard's  IRM  plan  in  July  1990.  (source:  COMDTPUB 
P5230.43,  18  Dec  90,  pp.  19-21). 
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TABLE  2:  USCG  INFORMATION  ".YSTEMS. 


Acronym: 

STARS: 

DMPS: 

DAFIS: 

IMAGE: 

LUFS: 

AMIS: 

DIAS: 

HNAIDS: 

ASIS: 

ACMS: 

CEDS: 

BEST: 

CBMIS: 

MMS: 

SAIL: 

ULMS: 

NEDMIS: 

CAD: 

HSMIS: 

TMPS: 

Cl  AMS: 

NIPS: 

HAZMAT: 

SHARKS: 

MADCAP: 

LAW: 

LDR: 

MSN: 

VIDS: 

AUXMIS: 

RBS: 

BRAINS: 

AMVER2: 

CASP: 

LOIS: 

BAMS: 

ATONIS: 

AAPS: 


System  Description: 

TRACEN  Petaluir;  Student  Tracking  and  Reporting  System 

International  Ice  Pa  ol  Iceberg  Data  Mgmt  and  Prediction  System 

Departmental  Accounting  and  Financial  Information  System 

Information  Systems  Division  Image  System 

Large  Unit  Financial  System 

Acquisition  Management  Information  System 

District  Interim  Accounting  System 

Headquarters  Accounting  System 

Aviation  Supply  and  Inventory  System 

Aviation  Computerized  maintenance  System 

Civil  Engineering  Data  System 

Base  Engineering  Support,  Technical 

G-ELM's  Configuration  Based  Management  Information  System 
Defense  Logistics  Materiel  Management  System 
G-ELM  System  for  Automated  Integrated  Logistics 
Unit  Logistics  Management  System 

Naval  Engineering  Division  Management  Information  System 

Naval  Engineering  Division  Computer-Assisted  Design  System 

Health  Services  Management  Information  System 

Tri-Service  Micropharmacy  System 

Clinic  Automated  Management  System 

NonFederal  Invoice  Processing  System 

Hazardous  Material  Information  System 

Safety/Health/Accident  Relational  Key  System 

Medical  and  Dental  Clinic  Automation  Program 

Legal  Automated  Workstation 

Legal  Document  Research 

Marine  Safety  Network 

Vessel  Identification  and  Documentation  System 
Auxiliary  Management  Information  System 
Recreational  Boating  Safety  System 
Bridge  Administration  Information  System 
Automated  Mutual  Assistance  Vessel  rescue  System 
Computer  Assisted  Search  Planning  System 
LORAN-C  Operations  Information  System 
Boat  Administration  and  Management  System 
Aids  to  Navigation  Information  System 
Automated  Aid  Positioning  System 


TABLE  3:  USCG  INFORMATION  SYSTEMS,  CONTINUED. 


Acronym: 

System  Description: 

ACMS: 

Aid  Control  and  Monitoring  System 

CAP: 

Computer  Assisted  Positioning 

ENMS: 

Electronic  Notice  to  mariners  System 

VTS  H/G  ADDS; 

VTS  Houston/Galveston  Automated  Bright  Display  System 

SARSIM: 

Search  and  Rescue  Simulation  Model 

TECS: 

Treasury  Enforcement  Communications  System 

JMIE: 

Joint  Maritime  Information  Element 

SPI: 

Security  Program  Improvements 

EMIS: 

Enforcement  Management  Information  System 

LEIS  II: 

Law  Enforcement  Information  System  II 

ELT/SIMS: 

Enforcement  of  Laws  and  Treaties/Shipboard  Info  Mgmt  System 

OPSTAT: 

Abstract  of  Operation  Software 

SRA: 

Computer  for  Service  Record  Automation 

PMIS/JUMPS  II:  Personnel  Mgmt  Info  System/Joint  Uniform  Military  Pay  System 

PDS: 

Personnel  Decision  System 

TRAVEL: 

Travel  Claim  Automation 

RIMS: 

Recruit  Information  Management  System 

PXM: 

Exchange  and  Morale  Systems 

PC  SYSTEMS: 

Civilian  Persoimel  Systems 

CIRMS: 

Classified  Information  Resource  Management  Support 

DRMIS: 

District  Reserve  Management  Information  System 

MOBSYS: 

Reserve  Mobilization  System 

COMDAC: 

Command,  Display  and  Control  System 

STC  II: 

Shipboard  Tactical  Computer  II 

NAVMACS: 

Naval  Modular  Automated  Communication  System 

IRIS: 

Incident  reporting  Information  System 

AISS: 

Automated  Information  System  Security 

CGSWOA: 

CG  Standard  Workstation  Contract  Office  Automation 

DRS: 

USCG  Data  Repository  System  Project 

MAP: 

Minicomputer  Acquisition  Project 

CDB/EIS: 

Corporate  Database  /  Executive  Information  System 

DIS: 

Distributed  Information  System 

DCS: 

Distributed  Computing  System 

GTC: 

Geographic  Tactical  Computer 

OIS: 

Operations  Information  Systems 

SATCOMM: 

Commercial  Satellite  Communications 

COMMSTA: 

Communications  Station  Automation 

HDN: 

Hybrid  Data  Network 
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E.  SUMMARY 


The  existing  suite  of  systems  are  vertically  oriented  file  processing  systems  which 
have  generally  been  built  piecemeal  around  processing  data  files  that  began  as  paper 
reports.  They  have  evolved  as  stovepipes  because  they  mirror  the  way  the  Coast  Guard 
structures  its  program  management.  They  provide  little  in  the  way  of  distribution  of  data 
among  Coast  Guard  information  users,  and  less  in  the  way  of  manipulation.  They  are 
hard  to  learn,  awkward  to  use,  and  sometimes  painfully  slow  at  transferring  information. 

Recommendations  for  improving  these  systems  are  put  forth  in  Chapter  VII.  But 
these  improvements  would  be  expensive  —  they  strike  at  the  very  hearts  of  the  systems. 
And  increasing  the  standalone  functionality  of  existing  systems  may  have  a  lower  payoff 
than  taking  the  next  step,  integrating  the  systems  and  re-engineering  our  information 
flow.  The  next  three  chapters  examine  the  benefits  of  cross-functional  systems,  and 
propose  a  system  that  would  increase  the  information  payoff. 
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IV.  CROSS-FUNCTIONALITY:  A  1 HEORETICAL  FOUNDATION 


The  Coast  Guard  has  recently  begun  focusing  on  cross-functional  systems  as  key 
strategic  elements  for  new  development;  the  concept  has  quickly  achieved  buzzword 
status.  Yet,  as  with  any  new  buzzword,  there  is  confusion  about  the  concept  of  cross¬ 
functionality  and  exactly  what  constitutes  a  cross-functional  system. 

This  chapter  examines  the  conceptual  basis  for  cross-functionality,  beginning  with 
a  discussion  of  organizational  structure:  the  need  to  organize,  structures  that  have  proven 
effective,  and  some  of  the  problems  inherent  in  organizing.  The  hierarchical  and  matrix 
structures  are  described.  Discussion  then  turns  to  minimizing  the  limitations  of  these 
structural  forms  by  establishing  aoss-functional  organizational  links,  and  means  of 
supporting  such  a  structure  through  information  technology.  Finally,  a  methodology  for 
conducting  the  strategic  MIS  planning  needed  to  achieve  such  a  complex  goal  is 
reviewed.  Chapter  V  will  propose  a  cross-functional  Operations  Information  System  for 
the  Coast  Guard,  relying  on  this  theoretical  framework. 

A.  THE  NEED  TO  ORGANIZE 

Simply  put,  human  organizations  have  become  far  too  large  and  complex  to  be 
understood,  analyzed,  and  controlled  in  their  monolithic  entirety.  Systems  theory  provides 
a  convenient  tool  for  breaking  these  huge  entities  down  into  manageable  chunks.  (Emery, 
1987,  p.  241). 
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1.  A  Systems  Theory  Approach 

A  large  system  has  several  subsystems,  each  of  which  has  its  own  subsystems, 
until  the  activity  at  hand  is  reduced  to  a  manageable  level,  typically  something  that  can 
be  performed  by  an  individual  or  small  group  of  individuals.  Each  subsystem  is 
responsible  for  a  certain  portion  of  the  overall  goals,  and  the  functions  carried  out  within 
it  are  closely  related  to  one  another,  at  least  as  compared  to  other  functions  at  that  same 
level  of  organization. 

Each  system  has  a  boundary,  which  defines  the  activities  considered  to  be 
integral  parts  thereof.  Things  outside  that  boundary  are  part  of  its  environment;  things 
that  cross  the  boundary  of  the  system  under  consideration  are  its  inputs  and  outputs. 
(Emery,  1987,  p.  241). 

As  the  number  of  subsystems 
within  an  organization  grows,  so  do  the 
number  of  interactions,  or  actions  that 
cross  subsystem  boundaries.  There  are 
two  primary  sources  of  interaction: 
coupling  and  shared  resources  (see 
Figure  2).  In  coupling,  the  output  of  one  subsystem  is  an  input  to  another,  so  that  any 
change  in  the  output  rate,  quality,  or  other  parameters  from  the  first  will  impact  the 
second.  The  same  is  true  of  shared  resources,  with  the  additional  complication  that  the 
output  from  the  first  subsystem  is  used  by  more  than  one  downstream  subsystem.  The 
output  of  the  first  is  a  resource,  shared  between  the  others;  like  any  other  resource,  a 


Figure  2:  System  interactions  (after  Emery, 
1987). 
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scarcity  produces  tough  decisions  for  the  people  who  allocate  it.  If  one  of  the 
downstream  subsystems  is  considered  more  important  than  the  other,  it  may  get  a 
proportionally  larger  share  of  the  reduced  resource;  however,  this  creates  even  more 
problems  if  the  process  moves  through  other  subsystems  further  downstream,  in  a  domino 
or  ripple  effect.  (Emery,  1987,  pp.  243-44). 

The  first  way  to  reduce  the  number  of  interactions,  and  therefore  the  degree 
of  complexity,  is  to  structure  the  organization  so  that  work  groups  (subsystems)  are 
responsible  for  closely-related  tasks.  If  this  is  the  case,  each  can  cope  with  as  many 
things  as  possible  internally.  In  a  similar  fashion,  closely-related  work  groups  should  be 
clustered  together.  Then,  if  a  certain  task  cannot  be  completed  within  the  subsystem,  it 
can  likely  still  be  handled  with  a  minimum  number  of  interactions  by  merely  passing  it 
up  one  level,  or  horizontally  to  a  related  subsystem.  This  technique  focuses  on 
eliminating  interactions  altogether  where  possible. 


Absent  the  ability  to  avoid 

interactions  by  structural  means,  as 
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2.  Black  Capacity 
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thereby  reducing  the  frequency  or  figure  3:  Techniques  for  decoupling 

systems.  (After  Emery,  1987). 


duration  of  interactions.  There  are 

several  techniques  for  accomplishing  this,  as  illustrated  in  Figure  3.  One  common 
technique  is  a  buffer,  which  collects  the  outputs  of  the  first  subsystem  until  the  second 
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is  ready  to  receive  them  as  inputs.  Another  is  building  systems  with  slack  capacity,  so 
that  the  rate  of  output  can  be  adjusted  depending  on  downstream  demand  or  upstream 
supply.  Finally,  one  can  increase  standardization.  The  consuming  system  decides  under 
what  range  of  conditions  it  can  operate;  if  the  output  from  the  first  system  is  within  the 
specified  limits  of  tolerance  (whether  these  limits  apply  to  rate,  quality,  or  some  other 
parameter),  then  the  subunits  do  not  need  to  coordinate.  Only  when  there  is  an  out-of¬ 
tolerance  condition  does  coordination  become  necessary.  (Emery,  1987,  p.  249). 

Interactions  due  to  shared  resources  are  a  harder  problem  than  those  due  to 
coupling.  One  of  the  best  ways  of  reducing  these  interactions  is  through  the  use  of  slack 
capacity,  despite  its  cost. 

When  the  organization  has  exhausted  ways  of  reducing  the  number  and 
complexity  of  interactions,  it  must  employ  a  coordination  mechanism.  This  may  be  a 
human  manager,  or  a  process  control  computer;  in  either  case,  the  task  is  to  coordinate 
the  interactions  between  the  various  subsystems.  This  may  involve  resource  allocation 
decisions  for  subsystems,  flow  control,  or  responding  to  out-of-tolerance  situations. 
Highly  coordinated  systems  are  often  referred  to  as  tightly  integrated,  and  are 
characterized  by  tightly  scheduled  inputs  and  outputs,  with  extensive  resource  sharing. 
This  has  the  advantage  of  greater  efficiency  for  the  system  as  a  whole,  allowing  it  to 
operate  with  fewer  buffers  and  less  slack  capacity.  Economies  of  scale  may  be  realized. 
Perhaps  most  important,  decisions  can  be  made  from  the  larger  perspective  of  the  system 
as  a  whole  (or  that  of  a  larger  set  of  subsystems),  rather  than  from  the  perhaps  suboptimal 
perspective  of  a  smaller  unit. 
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The  problem  of  highly  coordinated  systems  is  that  they  are  more  complex, 
involving  extensive  interactions  between  subsystems.  The  benefits  of  integration  versus 
independence  must  be  weighed  for  the  situation  at  hand,  and  an  appropriate  point  along 
the  spectrum  from  one  end  to  the  other  chosen.  Managers  are  now  able  to  factor  into  this 
decision  the  fact  that  information  technology,  if  properly  applied,  can  simplify 
coordination. 

2.  An  Information  Processing  Approach 

Galbraith  has  described  organization  design  principles  from  a  point  of  view 
centered  around  the  need  to  process  information: 

If  the  task  is  well  understood  prior  to  performing  it,  much  of  the  activity  can  be 
preplanned.  If  it  is  not  understood,  then  during  the  actual  task  execution  more 
knowledge  is  acquired  which  leads  to  changes  in  resource  allocations,  schedules, 
and  priorities.  All  these  changes  require  information  processing  during  task 
performance.  Therefore  the  greater  the  task  uncertainty,  the  greater  the  amount  of 
information  that  must  be  processed  among  decision  makers  during  task  execution 
in  order  to  achieve  a  given  level  of  performance.  (Galbraith,  1974). 

In  developing  his  analysis  of  the  organization's  structure,  Galbraith  presents 
a  model  (reproduced  in  Figure  4)  which  shows  seven  methods  for  coping  with  the  need 
to  process  information,  broken  down  into  three  categories.  First  are  those  which  reduce 
the  need  to  process  information  in  relatively  small  organizations.  Second,  and  quite 
similar,  are  methods  to  reduce  the  need  to  process  information  as  the  organization  grows 
increasingly  large  and  complex.  Third  are  methods  to  increase  the  ability  of  the 
organization  and  its  subunits  to  process  information.  Notice  that  the  first  two  of  these 
methods  correspond  closely  to  the  systems  theorists'  approach  of  increasing  independence 
of  subunits,  while  the  third  corresponds  to  increased  integration. 
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Galbraith's  methods  6  and  7 


are  the  areas  where  information  systems 
can  greatly  benefit  the  organization. 

Sharing  information  vertically  and 
horizontally  throughout  the  organization 
becomes  feasible  if,  for  example,  all 
departments  have  access  to  a  common 
database.  In  a  mail  order  firm,  a 
database  with  customer,  order,  and 

Figure  4:  Organizational  design  strategies 
supplier  information  could  be  integrated  (after  Galbraith,  1974). 

aaoss  all  functions  so  that  order¬ 
processing  clerks,  packing  and  shipping  clerks,  billing  clerks,  and  customer  service  clerks 
could  all  have  access  to  the  same  information.  Any  of  these  people  would  be  able  to 
immediately  get  necessary,  cunent  information  on  the  status  of  a  customer  or  and  order. 

B.  COMMON  ORGANIZATIONAL  STRUCTURES 

What  organizational  structures  have  evolved  from  this  theory?  In  this  section,  brief 
descriptions  of  two  broad  categories  are  presented.  The  descriptions  are  of  general 
concepts  of  the  structures,  not  specific  implementation  details,  and  are  presented  as  an 
introduction  to  the  concept  of  cross-functionality. 
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1.  The  Hierarchy 


Since  the  1920's,  when  Alfred  Sloan  refined  the  model  at  General  Motors,  the 
functional  hierarchy  has  been  the  most  common  structure  in  Western  organizations 
(Norton,  1988).  It  is  easy  to  understand,  and  embodies  the  span  of  control  concept.  It 
provides  clear  singularity  of  supervision  (or  command).  Finally,  it  fits  well  with  both  the 
systems  theory  and  information  processing  views  of  organization  design:  as  tasks  become 
increasingly  specialized,  they  are  moved  to  lower  levels  of  the  pyramid;  higher  levels 
coordinate  between  similar  but  distinct  sub-units. 

However,  a  major  drawback  is  that  hierarchical  organizations  can  have  their 
major  divisions  organized  along  only  one  of  several  possible  dimensions,  such  as 
function,  product,  market,  or  geographical  territory.  Figure  5  shows  a  typical  functional 
organization,  with  its  major  divisions  structured  about  the  tasks  people  perform,  or  the 
inputs  to  the  work  process. 


Figure  5:  Hierarchical  organization  structure  (after  Galbraith,  1974). 
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2.  The  Matrix 


The  one-dimensional  nature  of  the  hierarchy  has  led  several  researchers  to 
suggest  alternatives,  including  the  matrix  organization.  In  this  scheme,  sub-units  are 
organized  along  two  dimensions  at  once;  commonly  these  reflect  the  inputs  to  the  work 
process  (functional  specialties)  and  the  outputs  (products).  An  example  is  shown  in 
Figure  6.  This  firm  has  chosen  to  give  primary  control  to  managers  in  the  functional 
dimension;  other  firms,  with  a  more  product-oriented  culture,  may  reverse  the  roles. 


Formal  authority  over  the  product 
Technical  authority  over  the  product 


Figure  6:  Matrix  organization  structure  (after  Galbraith,  1974). 
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3.  Limitations  of  the  Hierarchy  and  the  Matrix 

In  their  popular  book,  In  Search  of  Excellence,  Peters  and  Waterman  survey 
many  U.S.  businesses,  striving  to  find  out  what  sets  the  most  successful  ones  apart. 
Among  the  eight  attributes  they  ascribe  to  an  excellent  organization  is  one  with  special 
significance  for  this  discussion  —  "Simple  form,  lean  staff:" 

Along  with  bigness  comes  complexity,  unfortunately.  And  most  big  companies 
respond  to  complexity  in  kind,  by  designing  complex  systems  and  structures.  Then 
they  hire  more  people  to  keep  track  of  all  that  complexity,  and  that's  where  the 
mistake  begins....  making  an  organization  work  has  e’'erything  to  do  with  keeping 
things  understandable  for  the  tens  or  hundreds  of  thousands  who  must  make  things 
happen.  And  that  means  keeping  things  simple.  (Peters  and  Waterman,  1982). 

The  essence  of  simplicity,  they  say,  is  picking  one  of  the  several  dimensions 
described  earlier  and  making  it  the  primary  focus  of  the  structure;  they  prefer  product, 
because  it  naturally  relates  everything  the  division  is  trying  to  accomplish.  The  thing  to 
avoid  is  a  complex,  intertwined  structure,  such  as  a  matrix,  where  each  employee  has  two 
(or  more)  bosses,  and  no  clear  picture  of  who's  in  charge  today.  They  do  not  advocate 
abolition  of  the  matrix  structure,  but  point  out  that  those  corporations  which  have 
implemented  it  successfully  all  specify  clearly  which  dimension  of  the  matrix  is  the 
primary  one.  This  reduces  the  potential  for  ambiguity  and  anarchy. 

However,  the  need  to  keep  things  simple  so  that  employees  can  cope  with  the 
size  of  the  organization  is  only  one  side  of  the  coin.  On  the  other  is  the  fact  that 
functionally  organized  units  frequently  need  to  send  information  outside  their  own 
function,  or  branch  of  the  hierarchy.  Norton  defines  the  building  blocks  of  organizations 
this  way: 
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An  activity  is  the  basic  element  of  organized  work....  A  process  is  a  collection 
of  activities  that  are  linked  together,  adding  value  by  converting  fundamental 
resources  to  achieve  organizational  objectives.... A  function  is  a  collection  of 
activities  that  are  organized  together  by  a  common  discipline....  Processes  are  the 
means  by  which  organizations  act  to  accomplish  their  objectives.  Functions  are  the 
way  organizations  group  people  to  achieve  the  benefits  of  specialization.  As  long 
as  processes  are  intrafunctional,  management  is  relatively  straightforward. 
However,  when  function  and  process  do  not  coincide,  we  create  unnatural  barriers 
to  organizational  effectiveness.  (Norton,  1988). 


C.  CROSS-FUNCTIONAL  ORGANIZATIONAL  STRUCTURE 

The  limitations  of  a  rigid  hierarchy  have  ted  Norton  and  others  to  propose  a  cross¬ 
functional  approach  to  organizing.  The  concept  focuses  on  analyzing  work  and 
information  flows  (Norton's  processes)  on  the  front  line.  It  is  similar  to  a  product- 
oriented  hierarchy,  which  emphasizes  the  organization's  outputs;  however,  it  goes  a  step 
further,  focusing  on  enabling  the  front-line  worker  to  handle  all  aspects  of  a  work 
activity.  Cross-functionality  occurs  when  a  single  organizational  unit  has  responsibility 
for  more  than  one  function.  A  classic  case  in  which  cross-functionality  would  yield 
dramatic  improvements  involves  a  bank  with  several  functional  departments: 

A  large  midwestem  bank  has  several  independent  business  units,  each  of  which 
maintains  its  own  customer  information  files  and  "guards  them  religiously." 
Customers  with  multiple  transactions  cannot  get  a  consolidated  statement.  Further, 
the  bank  has  no  idea  of  its  overall  exposure  to  any  particular  customer,  no  idea  of 
its  overall  profitability  by  customer,  no  way  to  truly  segment  its  market,  no  way  to 
cross-sell  its  services.  (Index  Group,  1990) 

The  quoted  article  points  out  the  benefits  that  would  be  achieved  by  building  a 
cross-functional  information  system:  all  departments  would  have  access  to  the  same 
information,  top  management  would  have  access  to  consolidated  information,  and 
customers  would  perceive  a  logical,  cohesive  entity.  This  case  is  illustrated  in  Figure  7. 
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Figure  7:  Banking  example  of  cross-functional  information  system. 


In  this  case,  the  bank  has  two  options  regarding  the  extent  to  which  it  employs 
cross-functionality.  First,  it  could  leave  things  at  the  level  cited,  integrating  the 
information  system  but  retaining  its  previous  structure  (loan  department,  savings 
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department,  etc).  Second,  it  could  redesign  not  only  the  IS,  but  also  its  structure.  This 
concept  is  examined  further  in  the  next  case. 

Where  the  activity  involves  the  customer,  cross-functionality  can  be  especially 
important,  in  the  interest  of  presenting  a  single  face  to  the  customer.  By  creating  an 
individual  position,  or  at  least  a  small  business  unit,  to  be  able  to  respond  fully  to  a 
customer's  query,  some  companies  have  achieved  enormous  advantages.  Here  is  a  real- 
world  example: 

Mutual  Benefit  Life,  the  country's  18th  largest  life  carrier,  has  reengineered  its 
processing  of  insurance  applications.  Prior  to  this,  MBL  handled  customers' 
applications  much  as  its  competitors  did.  The  long,  multistep  process  involved 
credit  checking,  quoting,  rating,  underwriting,  and  so  on  An  application  would 
have  to  go  through  as  many  as  30  discrete  steps,  spanning  five  departments  and 
involving  19  people.  At  the  very  best,  MBL  could  process  an  application  in  24 
hours,  but  more  typical  turn-arounds  ranged  from  5  to  25  days  —  most  of  the  time 
spent  passing  information  from  one  department  to  the  next  (emphasis  added). 
(Another  insurer  estimated  that  while  an  application  spent  22  days  in  process,  it  was 
actually  worked  on  for  just  17  minutes.) 

MBL's  rigid,  sequential  process  le-  to  many  complications.  For  instance,  when 
a  customer  wanted  to  cash  in  an  existing  policy  and  purchase  a  new  one,  the  old 
business  department  first  had  to  authorize  the  treasury  department  to  issue  a  check 
made  payable  to  MBL.  The  check  would  then  accompany  the  paperwork  to  the 
new  business  department. 

The  president  of  MBL,  intent  on  improving  customer  service,  decided  that  this 
nonsense  had  to  stop  and  demanded  a  60%  improvement  in  productivity.  It  was 
clear  that  such  an  ambitious  goal  required  more  than  tinkering  with  an  existing 
process.  Strong  measures  were  in  order,  and  the  management  team  assigned  to  the 
task  looked  to  technology  as  a  means  of  achieving  them.  The  team  realized  that 
shared  databases  and  computer  networks  could  make  many  different  kinds  of 
information  available  to  a  single  person,  while  expert  systems  could  help  people 
with  limited  experience  make  sound  decisions.  Applying  these  insights  led  to  a 
new  approach  to  the  application-handling  process,  one  with  wide  organizational 
implications  and  little  resemblance  to  the  old  way  of  doing  business. 
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MBL  swept  away  existing  job  definitions  and  created  a  new  position  called  a 
case  manager.  Case  managers  have  total  responsibility  for  an  application  from  the 
time  it  is  received  until  a  policy  is  issued.  Unlike  clerks,  who  performed  a  fixed 
task  repeatedly  under  the  watchful  gaze  of  a  supervisor,  case  managers  work 
autonomously.  No  more  handoffs  of  files  and  responsibility,  no  more  shuffling  of 
customer  inquiries....  MBL  can  now  process  an  application  in  as  little  as  four 
hours,  and  average  turnaround  takes  only  two  to  five  days....  case  managers  can 
handle  more  than  twice  the  volume  of  new  applications  the  company  could 
previously  process.  (Hammer,  1990). 


Figure  8:  Insurance  company  example  of  cross-functional  system  plus 
business  reengineering. 
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In  the  banking  example  cited  earlier,  top  management  limited  its  application  of  the 
cross-functional  concept  to  the  information  system.  They  used  information  technology 
as  a  means  of  enabling  better  integration  between  the  business  units,  as  in  Galbraith's 
method  6,  but  retained  the  existing  structure.  The  life  insurance  case,  on  the  other  hand, 
is  an  example  of  the  concept  of  cross-functionality  applied  not  merely  to  the  information 
system,  but  also  to  the  very  structure  of  the  organization.  The  restructured  company  is 
sketched  in  Figure  8.  Hammer  describes  this  further  step  as  "business  re-engineering:" 

It  is  time  to  stop  paving  the  cow  paths.  Instead  of  embedding  outdated  processes 
in  silicon  and  software,  we  should  "reengineer"  our  businesses:  use  the  power  of 
modem  information  technology  to  radically  redesign  our  business  processes  in  order 
to  achieve  dramatic  improvements  in  their  performance.  (Hammer,  1990). 

One  can  also  analyze  an  organization  from  the  viewpoint  of  the  independent- 
integrated  spectrum  of  organizational  "tightness."  On  the  face  of  it,  one  would  expect  to 
call  a  company  with  a  high  degree  of  integration  between  business  units  cross-functional, 
and  One  with  high  independence  would  not  be  considered  cross-functional.  Yet,  as 
shown  in  the  case  of  the  bank,  a  cross -functional  information  system  can  provide  the 
interface  that  allows  independent  units  to  act  in  a  cross -functional  manner,  despite 
geographic  or  functional  separation. 

D.  STRATEGIC  PLANNING  FOR  CROSS-FUNCTIONAL  SYSTEMS 

Cross-functionality,  whether  applied  merely  to  the  IS  or  to  the  very  structure  of  the 
organization,  will  require  a  level  of  planning  beyond  that  required  for  more  traditional 
applications.  Yet  this  does  not  imply  tighter  control  of  application  development,  nor  even 
more  formal  and  rigid  project  management  disciplines.  The  planning  most  needed  is  top 
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management  vision  about  ways  in  which  the  organization  can  gain  a  strategic  competitive 
advantage  (in  the  case  of  the  private  sector  firm)  or  provide  dramatically  improved 
services  to  the  taxpayer  (in  the  case  of  the  public  sector  agency). 

James  Wetherbe,  at  the  University  of  Minnesota's  MIS  Research  Center,  has 
proposed  a  model  for  this  process  that  helps  management  describe  the  key  needs  of  the 
organization  (Wetherbe,  1984).  His  four-stage-model,  along  with  a  fifth  stage  added  by 
James  Emery  (Step  2,  architecture;  Emery,  1991),  is  described  in  the  next  sections  of  this 
chapter  and  illustrated  in  Figure  9.  The  resultant  combination  is  used  as  the  basis  for  an 
analysis  of  the  Coast  Guard's  operational  information  flow  in  the  next  chapter. 


Wetherbe's  4-stag6  MIS  Planning  Model 


Emery's  S-stage  MIS  Planning  Model  Adaptation 


wma 

Si 

Figure  9:  Strategic  MIS  planning  (after  Wetherbe,  1984,  and  Emery, 
1991). 
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The  IS  plan  must  of  course  be 
linked  to  the  overall  business  plan.  Most 
organizations  have  some  sort  of  formal 
planning  process  in  which  top 
management  sets  out  a  vision  and  broad 
directional  guidelines.  Lower  level 
managers  then  generate  more  detailed 
plans  for  achieving  these  goals  in  their 
own  functional  areas.  There  is  one  potential  difference  with  the  IS  plan:  since 
information  technology  offers  the  potential  to  redesign  the  very  structure  of  the 
organization,  strategic  IS  planning  may  need  to  come  before  the  general  business  plan, 
and  the  two  will  be  involved  in  an  iterative  process.  These  relationships  arc  described 
in  Figure  10. 

1.  Stage  1:  Strategic  MIS  Planning 

The  method  Wetherbe  employs  for  strategic  planning  is  Strategy  Set 
Transformation  (King,  1979).  It  is  designed  to  provide  a  direct  link  to  overall 
organizational  strategic  planning. 

The  outputs  from  the  first  stage  include: 

•  an  accurate  perception  of  the  strategic  aspirations  and  directions  of  the  organization; 

•  a  new  or  revised  MIS  charter; 

•  an  assessment  of  the  state  of  the  MIS  function; 


Strategic  Business  Plan 


I 
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Suppoftlno 

Plans 


IS  Plan 


Figure  10:  Business  plan  linkage  with  IS  p 
Ian  and  other  supporting  plans. 
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•  and  a  statement  of  policies,  objectives,  and  strategies  for  the  MIS  effort. 

This  stage  is  carried  out  on  an  infrequent,  as-needed  basis,  perhaps  only  once 
in  a  few  years.  Later  stages  will  provide  the  year-to-year  detailed  plans. 

2.  Stage  2:  Information  Architecture 

Wetherbe  addresses  long-range  information  architecture  as  a  part  of  his  next 
stage.  Organizational  Information  Requirements  Analysis.  Emery  prefers  to  break  it  out 
as  a  stage  of  its  own,  as  outlined  herein.  (Emery,  1991).  The  architecture  is  of  critical 
importance  because,  properly  implemented,  it  serves  a  tremendous  role  as  an  enabling 
infrastructure.  Just  as  a  transportation  system  of  waterways,  railways  and  highways 
provide  an  enabling  infrastructure  for  firms  and  citizens  to  carry  out  free  enterprise 
throughout  the  nation  and  world,  an  information  architecture  provides  the  enabling 
infrastructure  for  exploitation  of  information  technology.  The  three  key  components  of 
the  architecture  are; 

•  An  organization-wide  telecommunications  network; 

•  A  shared  database; 

•  A  common  user  interface. 

These  components,  once  established,  provide  outstanding  benefits,  both  for 
systems  that  use  them  and  for  future  systems  development  within  the  organization.  First, 
a  robust  network  allows  easy  connectivity.  Users  can  communicate  with  the  central 
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database  and  with  each  other  in  a  transparent  way,  independent  of  time  differences  and 
geographical  separation. 


Second,  the  common  database  allows  users  and  management  to  retrieve 
information  in  ways  that  simply  weren't  possible  before  (witness  the  banking  example 
cited  earlier  in  this  chapter).  Information  from  other  functional  areas,  rather  than  being 
jealously  guarded  by  individual  departments,  would  be  available  to  enable  better  decision 
making  in  all  functional  units. 

Third,  and  perhaps  most  commonly  overlooked,  is  the  common  user  interface. 
This  allows  users  to  gain  immediate  productivity,  without  a  steep  learning  curve.  This 
aspect  has  been  one  of  the  weakest  points  of  many  systems;  program  logic  may  be 
excellent,  but  an  awkward  interface  discourages  users  from  spending  the  time  necessary 
to  learn  how  to  use  it. 

Fourth,  and  perhaps  most  important  for  the  organization’s  long-term 
information  processing  needs,  is  the  ease  with  which  new  applications  can  be  develc  ad 
after  this  enabling  infrastructure  is  in  place.  A  substantial  portion  of  the  complexity  and 
cost  of  new  applications  goes  to  the  three  areas  included  in  the  infrastructure  — 
communications,  data  management,  and  interface.  By  some  estimates,  the  user  interface 
alone  counts  for  70%  of  the  lines  of  code  in  microcomputer  applications.  This 
percentage  is  certainly  lower  for  minicomputer  or  mainframe  applications,  but  even  in  this 
environment  the  interface  accounts  for  an  increasingly  large  portion  of  system  resources. 
Given  the  success  of  the  Macintosh  interface  described  in  the  previous  section,  it  is 
arguable  that  the  interface  on  mainframe  applications  should  account  for  a  large  portion 
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of  complexity.  At  any  rate,  if  these  services  are  provided  by  the  infrastructure,  developers 
are  free  to  concentrate  on  program  logic,  allowing  them  to  deliver  systems  much  more 
quickly  and  at  substantially  lower  cost. 

3.  Stage  3:  Organizational  Information  Requirements  Analysis 

This  stage  involves  a  macro-level  analysis  of  the  information  needed  to  support 
the  strategic  plan.  It  should  not  be  confused  with  the  requirements  analysis  for  a  specific 
application  project,  which  includes  such  detail  as  repon  formats  and  display  design. 
Rather,  it  constitutes  a  statement  of  the  key  information  needed  in  various  parts  of  the 
organization,  its  sources  and  sinks.  Identifying  cross-functional  information  flows  (and 
potential  ones)  is  of  special  importance  here.  This  stage  is  repeated  annually  during  the 
planning  cycle. 

4.  Stage  4:  Resource  Allocation 

It  is  difficult  to  allocate  scarce  "resources  among  competing  organizational 
units,"  especially  if  the  "portfolio  of  potential  applications  does  not  fit  into  an  overall 
organizational  plan."  (Wetherbe,  1984).  The  goal  of  this  stage,  therefore,  is  to  carry  out 
resource  allocation  in  a  rational  way,  based  on  the  foregoing,  higher  level  plans. 
Wetherbe  lists  several  well-known  methods  for  allocating  resources  in  a  systematic  way: 
return  on  investment  (ROI),  zero-based  budgeting  (ZBB),  and  chargeout.  Each  of  these 
provides  a  structured  decision  making  methodology  for  prioritizing  individual 
application  development  projects,  and  allocating  fiscal  and  personnel  resources.  Each  is 
also  based  on  estimating  the  monetary  value  of  the  costs  and  benefits  associated 
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with  a  project.  However,  estimating  costs  and  benefits  of  information  systems  is 
notoriously  difficult,  so  another  method  is  proposed. 

A  method  not  included  in 
Wetherbe's  work,  but  which  can  provide 
a  valuable  analysis  of  projects  based  on 
their  respective  risks,  is  a  model 
proposed  by  McFarlan,  McKenney,  and 
Pybum  (1982)  of  technical  risk  versus 
organizational  and  structural^  risk.  This 
is  worth  describing  because  of  its 
explicit  categorization  of  risks  associated 
with  projects;  it  will  be  used  in  the  next  chapter  for  analyzing  risks  of  various  proposals 
for  Coast  Guard  systems.  The  model  is  depicted  in  Figure  11.  The  vertical  axis 
represents  organizational  and  structural  risks,  and  the  horizontal  axis  technical  risk. 
Examples  of  systems  are  placed  in  the  approporiate  quadrants. 

5.  Stage  5:  Project  Planning 

The  final  stage  is  concerned  with  developing  individual  systems  on  time  and 
within  budget.  Techniques  for  this  stage  include  the  traditional  system  development 
process  and  various  competing  methods.  Some  tools  that  help  manage  the  project  include 
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Figure  11:  McFarlan's  risk 
model  (McFarlan,  1982). 


assessment 


^Organizational  and  structural  risk  involves  resistance  to  change,  political  ramifications  of  the 
information  flow  in  the  organization,  and  the  power  represented  in  control  of  information.  All 
these  combine  to  form  a  very  subtle,  yet  complex  and  deeply  rooted  set  of  factors  to  consider 
in  this  regard. 
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PERT,  Gantt  charts,  and  Milestones.  A  great  deal  of  work  is  being  done  on  minimizing 
problems  of  system  development,  and  there  are  significant  developments  being  made. 
The  interested  reader  will  find  several  articles  and  books  devoted  to  this  topic  in  the 
Bibliography. 

E.  SUMMARY 

The  concept  of  cross-functionality  offers  significant  benefits  to  organizations.  It 
is  primarily  aimed  at  increasing  the  ability  of  the  organization  to  process  information. 
The  organization  can  achieve  gains  by  exploiting  this  improved  information  flow  within 
existing  structures,  or  can  use  the  technology  as  a  driving  force  for  business  reengineering 
within  the  organization. 
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V.  A  CROSS-FUNCnONAL  OPERATIONS  INFORMATION  SYSTEM 


This  chapter  proposes  a  Coast  Guard  cross-functional  Operations  Information 
System  (OIS),  built  on  the  theoretical  foundation  of  Chapter  IV.  The  primary  focus  is  on 
stage  2,  the  information  architecture,  and  stage  3,  the  organizational  information 
requirements  analysis.  A  robust  information  architecture  offers  great  benefits  by 
increasing  the  availability  of  information  to  those  who  need  it,  and  at  the  same  time 
decreasing  the  complexity  involved  in  developing  new  systems.  By  analyzing 
organizational  information  requirements,  it  is  possible  to  reengineer  the  flow  of 
operational  information  in  the  Coast  Guard,  dramatically  improving  information 
availability. 

The  proposal  is  followed  by  an  anecdotal  description  of  an  incident  using  the 
present  information  flow,  contrasted  with  a  description  of  an  incident  using  the  envisioned 
information  flow. 

A.  STAGE  I:  STRATEGIC  MIS  PLANxMNG 

This  stage  provides  the  linkage  between  the  strategic  organizational  plan  and  the 
information  systems  function.  This  has  already  been  performed  by  senior  management, 
as  discussed  in  Chapter  II.  The  results  of  this  linkage  are  framed  in  the  terms  of  this 


model  below: 


•  Strategic  aspirations  and  directions  of  the  organization  are  taken  from  the 
Commandant's  Strategic  Agenda  (COMDTINST  16000.21,  21  Sep  90).  They  are 
to  prevent  loss  of  life,  damage  to  property,  and  damage  to  the  environment;  and  to 
promote  safe  navigation  on  the  nation's  waterways  and  by  vessels  of  this  nation 
throughout  the  world. 

•  The  charter  specific  to  MIS  in  the  Strategic  Agenda  is  "to  increase  efficiency  and 
enhance  capability  through  Information  Resource  Management."  (COMDTINST 
16000.21,  21  Sep  90). 

•  A  general  guideline  which  has  significant  application  in  the  MIS  arena  is:  "Acquire 
standardized  equipment  which  improves  interoperability  with  other  agencies  and  is 
fully  supportable  within  Coast  Guard  or  other  federal  government  resources." 
(COMDTINST  16000.21,  21  Sep  90). 

•  The  state  of  the  MIS  function  is  discussed  at  length  in  Chapter  III  of  this  thesis. 
To  summarize,  there  are  on  the  order  of  100  separate  information  systems  in  use 
in  the  Coast  Guard,  with  almost  none  sharing  a  common  database.  There  is  some 
use  of  common  communication  networks,  and  improvements  are  being  made.  There 
is  almost  no  commonality  among  user  interfaces.  Several  major  systems  are 
undergoing  significant  enhancements,  and  a  concerted  effort  is  being  made  to 
encourage  cross-functionality  in  those  efforts. 

•  Commandant  Instruction  5230.41,  Information  Resources  Management,  describes 
policies,  objectives,  and  strategies  which  guide  the  MIS  effort.  Those  are  listed  in 
Chapter  II. 


The  sum  of  the  guidance  in  these  policies  is  clear:  the  Coast  Guard  is  dedicated  to 
improving  its  effectiveness  through  better  use  of  information.  There  is  a  mandate  to 
move  toward  cross-functional  systems. 


B.  STAGE  2:  INFORMATION  ARCHITECTURE 

The  enabling  role  of  the  information  architecture  canimot  be  overstated.  With  a 
solid  infrastructure  as  foundation,  development  of  individual  systems  becomes  much 
simpler.  The  availability  of  a  common  network  and  user  interface  mean  that  developers 
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will  not  have  to  expend  significant  resources  on  those  components,  but  simply  implement 
the  existing  infrastructure  components  in  the  new  system.  The  common  database  is  the 
most  demanding  of  the  three  infrastructure  components:  not  only  must  the  initial  database 
be  plaimed  carefully,  but  subsequent  addition  of  new  systems  will  require  careful  data 
modelling  to  fit  the  database  schema. 

1.  Telecommunications  Network 

The  Hybrid  Data  Network  (HDN)  is  the  Coast  Guard's  shore-based 
telecommunications  network.  It  presently  provides  dedicated  or  virtual  dedicated 
intercoimection  to  most  major  shore  units,  and  will  expand  to  serve  all  shore  units  with 
at  least  dial-up  access  by  1992.  It  has  been  implemented  as  the  transport  mechanism  for 
SARMIS  and  MSIS. 

In  order  to  provide  connectivity  with  mobile  units,  the  HDN  must  be 
augmented  by  establishing  radio-based  networks  that  coimect  with  the  HDN  at  key  nodes, 
such  as  Communication  Stations  and  Group  Communications  Centers.  Several 
technological  options  for  this  are  being  explored,  but  none  has  been  selected  for 
deployment  yet. 

HDN  traffic  should  be  prioritized,  much  as  AUTODIN  traffic  is  sorted  by  four 
classes  of  precedence.  Time-critical  traffic,  such  as  information  to  support  board/no¬ 
board  decisions  in  law  enforcement  cases,  would  preempt  most  other  types. 

In  order  to  support  the  improved  information  flow  that  will  be  proposed,  the 
radio  network  will  need  to  support  transinission  of  small  bursts  of  time-critical  data  at 
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sporadic  intervals.  This  requirement  points  to  packet-switching  as  the  solution,  and 
meshes  well  with  the  HDN  since  it  uses  the  X.25  packet  transmission  scheme. 

2.  Common  Database 

This  component  of  the  information  architecture  is  less  well  developed,  but  it 
has  received  some  attention.  First,  the  Coast  Guard  uses  Federal  Information  Processing 
Standards,  which  require  database  management  systems  that  support  the  SQL  standard. 
(FIPS  PUB  127).  Program  managers  developing  new  applications  are  encouraged  to  use 
either  Progress™  or  Oracle™  as  the  DBMS,  by  including  these  two  products  in  the 
Standard  Workstation  contract  for  ease  of  procurement.  Use  of  any  DBMS,  especially 
a  common  one,  will  be  a  vast  improvement  over  the  reliance  of  most  current  systems  on 
file  processing.  Second,  the  Coast  Guard  has  completed  a  set  of  Data  Element  Naming 
Conventions  (DENQ,  designed  to  provide  a  foundation  for  achieving  greater  homogeneity 
between  databases  in  future  developments. 

Developing  the  common  database,  while  certainly  not  a  simple  task,  need 
not  be  considered  impossibly  complex.  From  a  high-level  point  of  view,  there  are  only 
a  few  distinct  objects  about  which  the  Coast  Guard  tracks  information:  vessels,  people, 
and  various  types  of  incidents  or  characteristics  involving  them  (law  enforcement 
boarding,  SAR  case,  license  number,  etc  ).  With  a  concerted  effort  to  achieve 
commonality,  and  strict  application  of  the  the  Data  Element  Naming  Conventions,  a 
shared  database  can  be  created  and  new  systems  can  be  built  to  take  advantage  of  it. 
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To  illustrate  this  point,  consider  the  cross-functional  prototype  system 


described  in  Appendix  B.  That  system  illustrates  two  things: 


•  That  cross-functional  systems  for  the  Coast  Guard  are  technically  quite  feasible. 
This  is  evidenced  by  the  limited  resources  that  went  into  the  project.  Only  about 
150  hours  of  effort  (one  person-month),  from  two  people  with  no  prior  formal 
experience  in  database,  produced  a  working  microcomputer-based  prototype  system. 
It  is  certainly  not  a  production-quality  system,  but  if  such  a  limited  effort  can 
produce  a  cross-functional  system,  surely  a  professional  effort  can  yield  effective 
operational  systems. 

•  That  there  is  a  large  degree  of  redundancy  of  data  across  the  SAR  and  ELT  mission 
areas.  The  tables  below  summarize  the  data  elements  found  to  be  common  to  both 
mission  areas  in  this  prototype.^ 


Tables  4  and  5  summarize  the  TABLE  4:  REDUNDANCY  SUMMARY. 


data  redundancy  found  between  the  SAR 
Unit  Case  Folder  and  the  Report  of 
Boarding.  Most  costly  in  terms  of  time 
and  frustration  is  the  fact  that  field  level 
personnel  have  to  key  in  the  same  data 
to  several  systems.  Also,  the  Coast 
Guard  pays  a  heavy  toll  for  the  inability  to  correlate  information  contained  in  the 
independent  systems.  Finally,  there  aie  the  problems  of  data  inconsistency  across 
applications  and  of  redundant  mass  storage  at  computing  facilities. 


Data 

Element 

Type: 

Number 

of 

Items: 

Percent 

of 

Total: 

SAR 

10 

7.6 

ELT 

19 

14.4 

Common 

103 

78.0  1 

’  A  caveat  is  necessar}':  the  data  requirements  for  this  project  were  not  taken  from  SARMIS 
and  SIMS/ELT,  but  from  the  less  detailed  SAR  Unit  Case  Folder  (form  CG-16130)  and  Report 
of  Boarding  (form  CG-4100).  The  data  requirements  for  the  two  computerized  systems  would 
undoubtedly  show  less  redundancy,  but  the  concept  is  valid. 
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At  first  thought,  it  seems 


TABLE  5;  OBJECT  DETAILS. 


uicredible  that  nearly  80%  of  the  data  in 
the  two  systems  is  the  same.  However, 
when  one  thinks  about  the  type  of 
information  the  Coast  Guard  collects  in 
terms  of  data  objects,  the  reason  for  the 
overlap  becomes  clear.  The  Coast  Guard 
only  collects  data  about  a  limited  number 
of  real-world  objects  (people,  boats, 
airplanes,  etc),  yet  we  collect  it  in  several  independent  systems  that  were  developed  as 
stovepipes  to  support  vertically-oriented  functional  program  management.  Further,  it 
should  be  noted  that  this  comparison  reflects  only  two  systems.  If  it  had  included  others, 
it  would  likely  have  found  a  few  more  distinct  data  fields  but  a  large  number  of  common 
ones. 

Appendix  B  describes  the  real-world  objects  that  must  be  represented  in  a 
cross-functional  database  such  as  this,  and  depicts  their  transformation  into  the  relations 
and  relationships  of  the  database  schema. 

3.  Common  User  Interface 

In  this  arena,  there  is  great  room  for  improvement,  as  described  in  Chapter  III. 
In  one  positive  move.  Unisys,  the  CGSW  vendor,  has  initiated  two  efforts  to  bring 
improved  interfaces  to  BTOS.  First,  the  company  is  implementing  an  Applications 
Programming  Interface  (API)  called  XVT  (Extensible  Virtual  Terminal).  Applications 


Object: 

Data 

Elements: 

#  of 
Tables: 

Incident 

24 

3 

Weather 

20 

1 

Person 

25 

2 

Vessel 

34 

I 

SAR  Case 

10 

2 

Boarding 

19 

4 

Total 

132 

13 
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written  to  XVT  can  be  ported  to  any  of  several  graphical  operating  environments, 
including  Macintosh,  Presentation  Manager,  Motif,  and  Windows.  It  has  distributed 
development  toolkits  to  firms  who  write  software  for  the  BTOS  environment,  and  the  first 
of  those  new  applications  have  been  released.  Second,  the  company  plans  to  support 
Microsoft's  Presentation  Manager™  in  future  BTOS  releases. 

These  standards  will  provide  applications  with  a  similar  "look  and  feel."  If 
well  implemented,  they  will  also  provide  the  ease  of  learning  and  use  that  was  described 
in  Chapter  IV.  These  will  dramatically  decrease  the  time  spent  on  training  to  use  the 
systems,  and  increase  the  range  of  functionality  available  to  users. 

C.  STAGE  3;  ORGANIZATIONAL  INFORMATION  REQUIREMENTS 
ANALYSIS 

In  this  stage,  a  macro-level  analysis  of  information  flows,  along  with  sources  and 
sinks,  is  conducted.  It  focuses  on  key  information  needed  in  various  parts  of  the 
organi2;ation,  and  its  sources  and  sinks.  Identifying  cross-functional  information  flows 
(and  potential  ones)  is  of  special  importance. 

The  analysis  begins  with  a  deceptively  simple  question:  why  transfer  information 
from  one  place  to  another  in  the  first  place?  Before  analyzing  present  information  flows 
and  proposing  another  set  of  flows,  it  is  important  to  establish  the  reason  for  doing  so. 
The  answer  is  that  in  order  to  maximize  decision  making  effectiveness  service -wide,  the 
right  information  must  be  available  to  the  right  person  at  the  right  time.  The  decision 
to  be  made  may  concern  real-time  command  and  control  of  a  particular  case,  or  it  may 
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concern  long-range  planning  at  headquarters.  But  at  the  root  of  our  information 
collection  and  transfer  is  the  need  to  support  improved  decision  making. 

1.  Present  Information  Flow 

Simplified  diagrams  of  the  existing  information  flow  are  presented  for  the 
Search  and  Rescue,  Law  Enforcement,  and  Marine  Safety  mission  areas  in  Figures  12 
through  14.  For  the  first  two,  information  flows  from  its  source  at  the  field  unit  to 
various  sinks,  frequently  stopping  at  intervening  levels  for  review  and  aggregation.  The 
fastest  reports,  used  for  tactical  command  and  control,  are  by  voice,  radioed  to  a  shore 
site  and  then  relayed  by  telephone  up  the  chain  of  command  as  far  as  their  urgency 
dictates  they  need  go.  Shortly  after  the  incident  is  completed,  the  next  set  of  reports  go 
out;  these  are  by  message,  also  to  the  operational  chain  of  command.  They  provide  hard 
copy  documentation  of  the  incident,  and  are  reviewed  for  proper  handling  of  the  current 
incident,  analyzed  for  tactical  planning,  and  archived  for  legal  reference.  Finally,  the  last 
set  of  reports  go  into  computer  databases,  providing  program  managers  with  statistical 
summaries  for  long-range  trend  analysis,  large-scale  planning,  and  the  like. 

The  information  flow  for  the  Abstract  of  Operations  is  also  depicted  (Figure 
15).  In  many  ways  it  constitutes  a  follow-on  report  to  the  other  systems,  but  it  is  worth 
mentioning  separately.  The  system  epitomizes  the  argument  for  cross-functional  systems, 
and  represents  their  ultimate  goal.  These  reports  have  their  source  at  the  unit,  and  their 
sink  at  headquarters.  They  are  highly  condensed  cross-functional  aggregates,  and  the 
information  from  which  they  are  abstracted  has  almost  all  been  typed  into  the  several 
different  systems  in  some  form  or  another.  Yet  no  mechanism  for  retrieving  information 
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Figure  12:  SAR  mission  area  information  flow,  present  day. 


Figure  13:  ELT  mission  area  information  flow,  present  day. 
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Figure  14:  Marine  Safety  mission  area  information  flow,  present  day. 
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for  this  report  from  the  independent  systems  exists,  and  so  field  units  are  required  to 
consolidate  the  data  manually  and  submit  it  on  paper. 

Contrast  the  SAR  and  ELT  information  flow  with  that  depicted  for  Marine 
Safety.  In  the  latter  case,  information  is  entered  just  once,  interactively,  into  a  central 
database.  From  there,  it  is  available  nearly  immediately  to  any  authorized  user,  who  may 
query  the  database  to  get  just  the  information  needed.  Timeliness  and  information 
availability  are  greatly  enhanced.  The  field  unit  is  only  considered  an  information  source 
once:  at  the  time  it  updates  the  central  database.  From  then  on,  the  central  database 
becomes  the  source  of  almost  all  future  information  flows.  (This  is  admittedly  an 
oversimplification  —  Marine  Safety  units  do  complete  and  file  paper  reports  that  are  not 
generated  by  MSIS,  and  they  also  send  message  reports  of  their  activities  to  addressees 
that  do  not  have  access  to  MSIS.  However,  the  general  information  flow  is  much  more 
streamlined  for  the  marine  safety  mission  area  than  for  the  others). 

The  two  different  information  flows  result  in  vastly  different  information 
processing  workloads  for  the  field  units.  A  Marine  Safety  unit  submits  a  single  report 
of  an  incident,  either  while  the  incident  is  ongoing  or  immediately  afterwards.  A  unit 
conducting  Search  and  Rescue  or  Law  Enforcement,  on  the  other  hand,  submits  reports 
as  the  incident  is  ongoing,  then  message  reports,  and  finally  database  entries,  all  to 
different  information  sinks  and  at  different  times.  The  information  in  all  three  is  largely 
similar,  but  is  in  different  formats  and  data  standards  (e.g.,  no  commonality  in  date 
formats:  MMDDYY,  DDMMYY,  military  date-time  group,  etc). 


a.  SITREPS 


SITREPS  are  required  by  most  operational  commanders  at  four  hour 
intervals,  or  "as  the  situation  warrants."  Yet  even  if  sent  at  Operational  Immediate 
priority,  these  messages  generally  spend  most  of  an  hour  in  transit  to  the  commander,  so 
some  information  may  be  five  hours  old.  A  SITREP  is  basically  a  summary  of  events  to 
date  regarding  a  particular  case.  Operating  units  record  these  events  in  logbooks  or  on 
scrap  paper  as  they  happen,  then  draft  a  report  that  summarizes  them  for  the  commander 
every  few  hours. 

b.  Information  System  Entries 

Data  is  entered  into  the  information  system  after  the  fact  (except  for  some 
cases  of  MSIS).  It  may  be  entered  on  the  same  day  (SIMS/ELT),  or  perhaps  several  days 
or  weeks  later  (SARMIS).  But  regardless  of  the  actual  time  delay,  it  is  keyed  in 
separately  from  the  incident,  with  no  means  ror  capture  while  the  incident  is  ongoing. 
The  information  in  these  reports  is  largely  the  same  as  that  in  the  SITREPs  the  unit  sent 
out  during  the  incident;  although  it  may  be  in  slightly  different  form,  it  too  consists  of 
a  summary  of  the  individual  events  that  constituted  the  incident. 

2.  Reengineering  the  Information  Flow 

Information  technology  now  allows  us  to  dramatically  improve  the  situation. 
By  reengineering  the  information  flows,  we  can  significantly  ease  unit  workloads 
dedicated  to  information  processing,  provide  better  and  more  timely  information  to  the 
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commander,  increase  availability  of  information  to  other  users,  and  provide  crucial 
intelligence  information  to  the  field  unit. 

a.  Event-based  reporting 

The  basis  for  the  new  information  flow  is  a  redefinition  of  the  basic  unit 
of  information.  The  SITREP  has  serious  flaws  as  a  basic  unit,  because  of  the  inherent 
delay  and  the  inability  to  manipulate  the  information.  The  key  element  of  improving  the 
information  flow  is  already  in  place,  in  the  event  lines  of  SEER  and  SIMS/ELT.  Simply 
define  the  individual  events  that  heretofore  comprised  the  SITREPs  as  elemental 
information  units.  Rather  than  reporting  compilations  of  information,  units  can  report 
things  as  they  are  happening,  in  the  smallest  meaningful  granularity. 

What  attributes  make  SEER  events  so  suitable  as  the  basis  of  reporting?  To 
clearly  understand,  it  is  useful  to  consider  information  units  that  are  too  small  and  too 
large,  respectively.  For  instance,  an  event  might  be  described  by  several  data  fields  which 
convey  the  fact  that  "Our  unit  is  at  position  PP-PP.P,  at  time  Ti  l  l  ,  and  has  sighted  the 
vessel  described  as  follows:  {name,  document  number,  etc)"  All  these  data  elements  must 
be  present  in  order  for  the  information  to  be  meaningful. 

Smaller  information  units,  such  as  merely  the  name  of  a  vessel  sighted  or  the 
position  in  which  it  happens  to  be  at  that  time,  would  prove  to  be  largely  meaningless, 
because  they  fail  to  provide  the  needed  context. 

Larger  information  units  would  have  greater  utility,  but  would  suffer  from  too 
great  a  time  delay:  while  it  would  be  nice  to  know  that  the  vessel  in  question  proved  to 
have  illegal  drugs  aboard,  that  fact  will  not  become  known  for  an  hour  or  more  after  the 
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initial  sighting  of  the  vessel.  Delaying  the  sighting  report  for  greater  completeness  would 
render  the  earlier  information  valueless  for  real-time  command  and  control.  That  is  the 
situation  the  Coast  Guard  finds  itelf  in  today,  by  using  compilations  such  as  SITREPs  to 
summarize  incidents.  Even  an  improvement  such  as  sortie  reports,  where  information 
would  flow  from  the  unit  in  an  integrated,  cross-functional  report  that  describes  every 
event  that  occurred  during  a  particular  sortie  would  suffer  from  this  drawback. 

Figures  16  and  17  graphically  depict  the  proposed  information  flow,  and  one 
possible  phased  approach  to  achieving  it.  In  phase  1,  information  would  continue  to  flow 
from  the  unit  to  the  existing  stovepipe  systems.  OIS-1  could  then  query  the 
heterogeneous  systems,  serving  as  a  single  source  of  information  for  non-real  time 
information  needs.  This  phase  should  include  a  homogeneous  "front  end"  to  the  system, 
which  would  present  a  single  face  to  the  field  user  who  is  inputting  data;  it  would  collect 
each  piece  of  information  just  once,  and  route  it  to  the  appropriate  system  automatically. 

In  phase  2,  the  central  database  itself  would  become  integrated,  along  with 
communications,  and  all  users  would  conduct  transactions  interactively  and  directly. 


75 


Figure  16:  OIS  information  flow,  phase  1. 
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D.  STAGE  4:  RESOURCE  ALLOCATION 

The  goal  of  this  stage  is  to  allocate  scarce  resources  between  competing  proposals 
in  a  rational  way,  based  on  the  foregoing  higher  level  plans  and  some  set  of  comparative 
measures.  The  traditional  measure,  cost-benefit  analysis,  is  of  questionable  worth  for 
evaluating  IS  projects,  because  of  the  great  uncertainties  associated  with  both  costs  and 
benefits  of  information  systems.  As  one  alternative,  Chapter  FV  described  McFarlan's  risk 
analysis  model;  that  is  presented  again  here,  this  time  describing  Coast  Guard  systems. 
Another  way  of  thinking  about  these  systems  is  developed  in  Chapter  VI.  It  proposes  that 
motivating  cross-functionality  and  a  common  information  architecture  can  best  be  done 
by  drawing  an  analogy  to  public  goods  in  classical  microeconomic  theory. 

It  is  felt  that  existing  Coast  Guard  systems  are  low  risk,  technologically  and 
structurally  (see  Figure  18).  However,  when  systems  are  combined  in  a  cross-functional 
manner,  two  things  happen: 


•  First,  because  of  the  increased  size  and  complexity  of  the  integrated  system  over 
the  standalones,  the  technical  risk  increases  somewhat.  However,  the  scope  of  the 
proposed  OIS  is  nowhere  near  the  limits  of  current  system  development  capabilities, 
so  it  is  not  far  out  along  the  axis. 

•  Second,  because  of  the  implications  which  the  integrated  system  has  for  change  in 
the  organization,  the  structural/behavioral  risk  increases  dramatically.  A  large  part 
of  this  risk  is  the  reluctance  of  those  who  presently  control  certain  information  to 
share  it,  since  information  entails  power  within  the  organization. 
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Figure  18;  Coast  Guard  systems  analyzed  using  McFarlan's  risk  assessment  model. 
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Even  for  the  scope  of  the  proposed  OIS,  it  is  felt  that  the  organizational/structural 
risk  far  outweighs  the  technical  risk  (see  Figure  18).  Relational  database  theory  and 
technology  are  at  a  level  where  associating  data  elements  with  one  another  in  a 
meaningful,  flexible  way  through  the  use  of  a  DBMS  is  relatively  routine,  and  eminently 
achievable.  This  is  not  to  say  that  the  technical  risks  arc  nil;  the  system  is  fairly 
complex,  and  requires  careful  thought  and  planning  to  build  the  database  schema  in  a 
useful,  flexible  way.  But  the  higher  risks  are  certainly  along  the 
structural/bchavioral/political  axis  of  McFarlan’s  model. 
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E.  STAGE  5;  PROJECT  PLANNING 


OIS  is  envisioned  as  a  system  of  systems,  wherein  program  managers  continue  to 
develop  individual  systems  for  their  mission  areas  in  a  relatively  decentralized  fashion. 
In  this  way,  they  will  ensure  that  the  system  meets  their  needs,  have  the  ability  to  make 
changes,  and  other  benefits  associated  with  decentralization.  However,  systems  will  no 
longer  be  developed  "in  a  vacuum,"  where  the  program  manager  builds  all  the  pieces  of 
the  system  and  controls  it  in  its  entirety.  Rather,  each  system  will  be  based  on  the 
common  infrastructure,  and  reap  the  benefits  of  less  development  time  devoted  to  those 
Items. 

Incorporating  the  common  network  and  user  interface  in  new  applications  should 
be  almost  effortless.  Implementing  the  common  database  would  not  be  quite  as  simple; 
new  systems  must  be  carefully  fitted  to  the  existing  database,  employing  existing  relations 
where  possible,  and  melding  new  relations  and  relationships  into  the  schema  as  well.  The 
total  cost  of  the  new  system,  however,  would  be  significantly  lower  than  if  it  had  been 
developjed  entirely  on  its  own. 

F.  AN  ANECDOTAL  DESCRIPTION 

The  benefits  to  be  realized  fi’om  an  integrated  Operations  Information  System  may 
become  even  more  obvious  if  described  anecdotally.  The  next  two  subsections  depicting 
the  existing  and  envisioned  information  flows  in  a  hypothetical  scenario  and  the  ways  in 
which  Coast  Guard  decision  makers  at  all  levels  will  be  aided  by  availability  of  better 
information. 
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1.  Present  Information  Flow 


Coast  Guard  units  on  law  enforcement  patrols  routinely  sight  and  identify 
hundreds  of  vessels.  They  choose  to  board  a  few  of  these,  ensuring  compliance  with 
many  federal  laws  —  e.g.,  those  governing  boating  safety  and  documentation,  fisheries, 
smuggling,  and  illegal  immigration.  The  decision  on  whether  or  not  to  board  a  particular 
boat  is  based  on  several  factors,  including  the  number  and  description  of  other  vessels 
nearby,  course  and  speed  the  boat  has  been  pursuing,  and  apparent  intentions.  While  in 
no  way  definite,  these  factors  act  as  very  general  indicators  of  whether  or  not  a  boat  may 
be  in  violation  of  any  of  the  afore -mentioned  laws,  and  serve  as  bases  for  decision 
making.  Other,  much  more  informative,  factors  in  the  decision  include  intelligence 
reports,  registration  information,  recent  sighting  reports  confirming  a  trackline  along  a 
known  smuggling  route,  and  more.  These  are  available,  but  take  significant  time  and 
effort  to  retrieve:  a  voice  radio  call  to  a  Coast  Guard  shore  site,  then  several  telephone 
calls  and  computer  inquiries  against  remote  databases,  and  a  return  radio  call  to  the 
patrolling  unit.  This  process  takes  the  better  part  of  an  hour  under  the  best  of 
circumstances;  if  the  shore  site  is  busy,  the  information  may  not  be  available  at  all.  And 
if  more  than  a  few  queries  per  day  come  in,  the  shore  site  is  overloaded. 

The  result  of  this  torturous  information  flow  is  that  when  a  patrol  unit  decides 
to  board,  it  rarely  does  so  on  the  basis  of  information  gleaned  beforehand  from  shoreside 
databases.  The  boarding  party  goes  across  without  knowing  the  registered  owner  or  any 
intelligence  about  the  vessel.  People  on  board  may  have  outstanding  arrest  warrants,  or 
even  be  described  as  "armed  and  dangerous,"  but  that  information  rarely  gets  to  the  patrol 
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unit  before  they  go  aboard.  It  would  be  much  safer  to  know  such  things  ahead  of  time, 
but  current  procedures  and  technology  do  not  allow  it. 

2.  Proposed  Information  Flow:  Event-based  Reporting 

Now  let  us  consider  the  same  scenario,  but  with  an  event-based  OIS  in  place. 
A  patrolling  cutter  sights  a  vessel,  triggering  a  real-time  OIS  information  flow.  Cutter 
personnel  record  the  vessel's  identifying  characteristics  (name,  document  number,  length, 
color,  etc)  in  their  local  CGSW.  The  shipboard  system  immediately  sends  this  event 
report  out  over  its  dedicated  HDN  link  to  the  OIS.  Since  the  event  was  an  identification, 
it  also  automatically  addresses  it  to  several  other  recipients,  including  the  operational 
commander  and  "information"  addressees  specified  by  the  unit  commander.  The  OIS, 
recognizing  the  event  report  as  an  identification,  automatically  updates  the  database,  and 
also  issues  a  query  against  it.  It  retrieves  a  "tactical  decision  history"  of  that  vessel  — 
recent  sightings,  boardings,  violations,  and  intelligence.  It  also  produces  a  list  of  people 
associated  with  the  boat:  owner,  operator,  and  others,  along  with  any  outstanding  warrants 
or  intelligence  reports.  This  information  is  returned  to  the  patrolling  cutter  within  seconds 
after  the  identification  information  was  sent  out,  and  a  copy  forwarded  to  the  operational 
commander.  The  cutter  CO  can  then  make  an  informed  decision  about  whether  to  board 
the  vessel  in  question,  and  the  information  contained  in  the  identification  event  is 
available  to  all  parties  who  need  it  in  near  real  time. 

Information  no  longer  flows  up  the  chain  of  command,  stopping  along  the  way 
for  review  and  aggregation.  Instead,  it  becomes  immediately  available  to  all  parties  who 
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need  it.  Each  information  user  can  issue  queries,  or  design  entire  applications,  to 
aggregate  the  OIS  data  into  the  appropriate  granularity  for  the  task  at  hand. 

G.  THE  USER  INTERFACE  REVISITED 

The  OIS  user  interface  should  rely  heavily  on  integrated  sensors  and  flexible  input 
devices.  Integrated  sensors  offer  the  ability  to  completely  avoid  human  data  entry,  by 
automating  the  collection  of  certain  frequently  used  data.  An  interface  based  on  National 
Marine  Electronics  Association  (NMEA)  standards  would  link  a  shipboard  system  directly 
to  the  integrated  navigation  packages  for  collection  of  position  information.  Similar 
possibilities  exist  for  weather  sensors. 

Flexible  input  devices  will  be  key  components  of  the  user  interface.  The  mere  act 
of  writing  can  be  a  challenge  aboard  mobile  units,  especially  small  cutters  or  boats. 
Recognizing  this,  many  units  have  stopped  trying  to  write,  and  begun  using  tape  recorders 
to  capture  radio  communications  and  other  significant  events  for  later  transfer  to  the  ship's 
log.  Incorporating  voice  recognition  processors  would  allow  hands-off,  natural 
interaction  with  the  information  system.  Currently  available  off-the-shelf  products  allow 
discrete  speech  recognition  with  excellent  accuracy  for  a  few  hundred  dollars. 

There  will  be  some  difficulty  in  implementing  this  technology,  because  of  high 
background  noise  in  many  mobile  environments.  In  cockpits  and  on  coxswain  flats,  loud 
and  varying  engine  and  wind  noises  are  the  rule.  However,  by  using  helmet-mounted 
microphones  these  barriers  can  be  overcome.  Variability  of  speech  patterns  from  one 
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individual  to  another  hampers  current  generation  systems,  but  is  easily  overcome  by  using 
a  system  that  is  trained  by  the  individual  who  will  be  operating  it. 

In  some  cases,  it  is  not  possible  to  avoid  the  need  to  write  or  key  in  data.  For  these 
situations,  the  Coast  Guard  should  incorporate  pen-based  computers,  which  will  be 
available  off-the-shelf  this  year.  The  first  generation  of  these  are  especially  well-suited 
to  form  fill-in,  such  as  the  Coast  Guard  would  be  interested  in. 

H.  THE  OVERALL  VIEW  OF  OIS 

A  key  advantage  to  developing  a  system  such  as  this  would  be  its  reliance  on  the 
organization-wide  information  architecture  to  the  greatest  extent  possible.  OIS  would 
consist  of  several  applications  sharing  a  common  database,  communicating  via  a  common 
network,  and  presenting  a  single  face  to  the  user  through  a  standard  user  interface. 
Systems  that  are  presently  independent  would  be  migrated  to  this  shared  environment,  and 
become  modular  components  of  the  system. 

By  developing  the  system  in  this  fashion,  it  remains  relatively  simple  to  upgrade 
or  replace  an  application  module.  The  remainder  of  the  system  would  be  undisturbed. 
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VI.  MOTIVATING  SYSTEM  DEVELOPMENT:  SPECIAL  CONSIDERATIONS 


A  robust  information  architecture,  and  development  of  cross-functional  systems  that 
rely  on  such  an  architecture,  are  critically  important  to  the  organization's  effective  use  of 
information.  Yet  motivating  the  development  of  these  specialized  projects  is  not  easily 
done  in  an  atmosphere  where  program  managers  develop  systems  independently  of  each 
other,  and  compete  for  budget  dollars.  This  chapter  will  be  devoted  to  further  analysis 
of  the  special  concerns  surrounding  motivation  of  cross-functional  systems  and  the 
information  architecture.  It  will  draw  distinctions  between  the  information  architecture, 
cross-functional  systems,  and  application  systems,  and  discuss  the  ramifications  these 
distinctions  have  for  development  of  the  various  classes  of  systems. 

The  analysis  here  will  be  framed  largely  in  terms  of  the  degree  of  centralization 
versus  decentralization  of  systems,  and  the  proposed  solutions  will  lean  toward  economic 
motivation  of  system  developers.  To  this  end,  those  topics  arc  reviewed  first. 

A.  CENTRALIZATION  VERSUS  DECENTRALIZATION 

The  debate  over  centralization  versus  decentralization  in  organizations  is  much 
wider  than  just  information  systems.  Of  course,  the  debate  existed  before  computers  did, 
and  the  issues  at  stake  have  changed  little.  The  important  questions  regard  what  type  of 
organizational  structure,  and  information  systems  structure,  are  best  for  the  smooth 
functioning  of  each  organization.  The  remainder  of  this  section  recaps  the  typical 
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arguments  in  favor  of  centralization  and  decentralization,  relying  heavily  on  Wetherbe 
(1984,  pp.  297-300). 

1.  Arguments  in  Favor  of  Decentralization 

a.  Proximity  to  Users 

If  systems  are  developed  by  personnel  close  to  the  problem,  they  will  tend 
to  be  much  more  likely  to  produce  workable  solutions.  As  systems  grow  more  and  more 
complex,  it  becomes  increasingly  important  to  have  close  interaction  between  users  and 
developers.  Only  in  this  way  will  the  resulting  systems  meet  user^'  needs.  It  is  very 
difficult  to  specify  rec  Jrements  for  a  complex  information  system  in  advance  —  users 
are  not  familiar  enough  with  what  technology  can  do  for  them,  and  developers  (especially 
if  they  are  remote)  are  not  familiar  enough  with  the  problem.  By  decreasing  the  isolation, 
one  can  improve  the  resultant  system. 

b.  Speed  of  Response 

Decentralized  computer  hardware  and  support  personnel  can  respond  more 
quickly  to  user  needs  than  centralized  resources. 

c.  Profit  and  Loss  Responsibility 

The  costs  of  decentralized  resources  can  be  easily  charged  to  the 
responsible  departments,  making  them  more  sensitive  to  the  tradeoff  of  cost  versus  value 
derived  from  the  system.  The  departments  will  be  much  more  prone  to  weigh  requests 
carefully  if  they  are  responsible  financially. 
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2.  Arguments  in  Favor  of  Centralization 

a.  Economies  of  Scale 

For  very  expensive  items,  it  is  most  cost-effective  to  use  only  a  few,  and 
centralize  them  so  that  the  entire  organization  has  access  to  them.  This  applies  especially 
to  large  computer  hardware  items,  and  most  of  all  to  organization-wide  databases.  It 
would  be  technically  possible  to  keep  separate  copies  of  the  complete  OIS  database  at 
several  locations,  but  the  cost  of  doing  so  would  be  extreme.  Beyond  the  mere 
duplication  of  hardware  is  the  huge  problem  of  maintaining  consistency  of  the  distributed 
databases.  It  is  much  more  feasible  to  access  a  central  database,  despite 
telecommunications  costs,  than  to  try  to  maintain  a  consistent  distributed  database. 
Research  may  change  this,  but  for  the  foreseeable  future,  centralized  data  will  be  by  far 
the  most  practical. 

b.  Limited  Personnel  Resources 

Specialists  in  any  field,  including  computers  and  systems,  are  scarce  and 
exp)ensive  resources.  By  centralizing  them,  it  is  possible  to  achieve  a  sort  of  "personnel 
economy  of  scale."  At  the  central  location,  they  are  more  likely  to  be  kept  fully  occupied 
than  if  distributed,  so  it  makes  economic  sense  to  keep  them  there. 

c.  Organization-wide  Consolidation  of  Information 

"Financial  and  operating  data  are  readily  consolidated  for  reporting  and 
evaluation  purposes.  Without  centralization,  consolidation  is  usually  obstructed  by 
incompatibilities  of  different  system  design,  coding  schemes,  and  data  formats." 


(Wctherbe,  1984,  p.  298).  This  quote  strikes  at  the  heart  of  the  argument  for  cross¬ 
functionality.  The  Coast  Guard  should  design  cross-functional  systems,  systems  that  rely 
on  a  common  architecture.  In  this  way,  it  is  possible  to  reap  the  advantages  of 
decentralized  development  and  control  and  those  of  centralized  information  consolidation 
at  the  same  time. 

d.  Ease  of  Control 

Centralized  resources  are  easier  to  control.  However,  this  ease  of  control 
is  counterbalanced  by  a  tendency  to  stifle  initiative.  Wetherbe  states  the  classic  argument 
that  "through  centralized  systems  development,  uniformity  can  be  achieved."  (Wetherbe, 
1984,  p.  298).  But  with  the  advent  of  client-server  or  distributed  systems,  the  entire 
system  need  not  be  centralized.  By  centralizing  the  bare  minimum,  the  critical 
information  architecture,  and  adhering  to  the  rapidly  developing  open  standards,  it  is 
possible  to  have  uniformity  while  still  achieving  the  advantages  of  decentralized  system 
development. 

B.  PUBLIC  GOODS  AND  SERVICES 

The  next  step  in  developing  the  special  distinctions  between  the  information 
architecture,  cross-functional  systems,  and  application  systems  is  to  describe  what  it  is 
that  typifies  a  "public  good."  The  discussion  begins  with  a  definition  of  the  limited  roles 
government  should  take  in  a  marketplace,  according  to  classical  microeconomic  theory. 
Later,  the  environment  for  systems  development  in  the  Coast  Guard  will  be  compared  to 
a  marketplace  for  goods  and  services.  In  this  analogy,  program  managers  are  viewed  as 
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utility-maximizing  individual  consumers,  and  the  office  of  Command,  Control,  and 
Communications  is  viewed  as  a  supervisory  authority  like  the  "government"  of  that 
theory. 

In  most  instances,  of  course,  a  free  market  society  experts  government  to  let  the 
marketplace  function  on  its  own.  However,  there  are  four  cases  in  which  government 
should  become  involved: 

•  To  provide  a  special  category  of  goods  and  services,  normally  referred  to  as  public 

goods. 

•  To  correct  imperfections  (through  regulation). 

•  To  redistribute  income  (through  taxes  and  subsidies). 

•  To  protect  rights  of  parties.  (Gates,  9/18/90) 

A  classic  example  of  public  goods,  with  room  for  discussion  of  the  government's 
other  roles,  is  the  public  network  of  roads  and  bridges.  It  provides  society  with  a  vital 
ability  to  transport  goods  and  services.  However,  this  network  was  not  developed  by  the 
people  and  companies  who  use  it.  Rather,  it  was  developed  by  the  govermnent  (which 
is  regarded  here  as  a  monolithic  whole,  with  the  different  levels  of  government  ignored). 
The  majority  of  the  system  was  directly  funded  by  the  government,  and  is  completely 
open  to  public  use. 

In  some  cases,  individuals  or  firms  choose  to  build  their  own  roads,  especially  short, 
special-purpose  links  to  the  public  roadway  network.  This  is  certainly  permitted,  even 
encouraged.  However,  these  private  roads  must  be  built  according  to  government 
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standards,  and  must  not  be  built  so  as  to  be  illegal.  These  standards  illustrate  the 
regulatory  powers  of  government. 

Finally,  government  may  decide  that  society  would  benefit  from  private 
development  of  certain  roads  or  connecting  thoroughfares,  but  not  feel  that  they  are 
completely  in  the  interests  of  the  general  public.  It  may  then  decide  to  encourage  private 
entities  to  develop  those  roads  by  offering  a  subsidy.  ITiis  may  be  viewed  as  a  cost¬ 
sharing  arrangement  that  provides  benefits  for  the  private  entity  and  also  for  society.  In 
economic  terms,  the  government  subsidy  allows  the  private  entity  to  "internalize  the 
external  benefits"  —  since  the  private  entity  is  doing  something  that  benefits  society, 
society  assumes  a  portion  of  the  costs.  Conversely,  if  a  private  entity  is  doing  something 
that  costs  society,  such  as  polluting  the  air  or  creating  a  noisy  environment,  government 
may  impose  a  tax  on  the  entity.  The  amount  of  this  tax  approximates  the  cost  to  society 
of  the  entity's  activity.  (Rasmussen  and  Haworth,  1979,  p.  458). 

In  summary,  the  government  (or  some  regulatory  authority)  has  several  important 
roles  in  the  marketplace,  which  will  be  compared  to  the  roles  for  a  regulatory  division 
within  the  Coast  Guard.  These  roles  are: 

•  To  provide  goods  and  services  that  benefit  society  as  a  whole 

•  To  regulate  private  economic  activity,  preventing  illegal  or  immoral  acts. 

•  To  help  private  entities  realize  rewards  for  indirect  benefits  that  they  create  for 
society,  in  the  form  of  a  subsidy.  Conversely,  to  ensure  that  indirect  costs  they 
impose  on  society  are  made  real  for  the  private  entities,  in  the  form  of  a  tax. 
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C.  DEVELOPING  APPUCATION  SYSTEMS 


Application  systems  fill  special  end-user  needs,  and  are  frequently  best  developed 
in  a  decentralized  fashion.  System  developers  are  much  closer  to  the  users,  so  the  close 
coordination  that  is  vital  to  a  successful  development  effort  is  much  easier.  Also,  the 
costs  and  benefits  of  an  information  system  proposal  are  likely  to  be  weighed  much  more 
carefully  if  they  are  chargeable  to  the  department  making  the  proposal. 

The  program  mzmagers  at  Coast  Guard  headquarters  are  the  ideal  sponsors  of  the 
existing,  independent  application  systems  (MSIS,  SARMIS,  LEIS,  etc).  They  have  a 
more  direct  interest  in  the  success  or  failure  of  their  MIS  than  any  other  office.  They  are 
likely  to  consider  the  costs  carefully  in  relation  to  other  program  expenditures.  And 
although  they  are  not  decentralized  geographically,  they  are  significantly  more 
decentralized  organizationally  than  the  Information  Systems  Division,  G-TTC. 

Considered  in  terms  of  the  economic  marketplace  analogy,  program  managers  act 
largely  to  maximize  their  utility  for  their  own  programs,  with  little  consideration  for  the 
benefits  or  costs  their  efforts  may  have  to  other  programs,  nor  for  the  benefits  they  may 
be  able  to  receive  from  other  programs.  For  stovepipe  application  systems,  this  situation 
is  acceptable,  in  fact  desirable  —  applications  are  optimized  for  the  good  of  the  programs 
they  serve.  However,  when  systems  must  become  cross-functional,  this  situation  needs 
massaging  in  order  to  provide  the  best  solution. 
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D.  DEVELOPING  CROSS-FUNCTIONAL  SYSTEMS 


The  program  managers  also  have  a  vital  interest  in  any  cross-functional  system  that 
affects  their  programs.  Each  would  certainly  like  to  have  complete  control  over  such  a 
system,  to  ensure  it  meets  program  needs  perfectly.  However,  by  their  very  nature, 
cross-functional  systems  benefit  the  entire  organization,  not  just  a  single  department.  It 
is  difficult  or  imp)Ossible  to  optimize  systems  for  the  good  of  both  the  whole  organization 
and  of  individual  departments.  Therefore,  it  behooves  the  organization  to  devise  a 
mechanism  for  ensuring  cross-functional  systems  are  optimized  for  the  good  of  the 
whole,  and  if  necessary  be  sub-optimized  for  the  individual  divisions. 

This  concept  is  already  recognized  by  the  Coast  Guard.  Coast  Guard  IRM 
Principles  clearly  state  that  "individual  IRM  solutions  may  be  suboptimized  for  the  greater 
good  of  the  Coast  Guard."  (COMDTINST  5230.41,  31  May  90,  p.  2).  Program  managers 
are  indeed  cooperating  on  next  generation  systems  development  at  a  level  not  seen  before. 
However,  there  is  no  firmly  established  mechanism  for  encouraging  them  to  adhere  to  this 
principle,  and  no  means  of  discouraging  them  from  continuing  independent  system 
development  should  they  choose  to  do  so. 

The  roles  of  government  in  the  marketplace  suggest  a  solution  to  this  dilemma.  Just 
as  government  can  use  subsidies,  taxes,  and  regulation  to  encourage,  discourage  or 
prohibit  certain  behaviors  on  the  part  of  utility-maximizing  individuals  or  firms,  G-TTC 
should  be  empowered  to  use  these  mechanisms  to  foster  development  of  cross-functional 
systems.  The  IRM  Principles  already  state  the  desired  result,  that  systems  be  built  for  the 
good  of  the  whole.  But  without  a  mechanism  for  implementation,  a  principle  may  do 
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little  for  the  actual  state  of  affairs.  The  principle  should  be  embodied  in  a  'regulatory 
system,"  requiring  optimization  for  the  good  of  the  whole.  This  kind  of  control  rests  with 
the  budgetary  process,  where  G-T  has  had  no  authority  until  recently,  and  even  now  only 
review,  not  approval.  The  role  of  G-T  in  the  budgetary  process  should  be  enhanced  to 
provide  the  necesary  mechanism  for  encouraging  cross-functional  systems  and 
discouraging  stovepipes. 

The  regulatory  system  would  encourage  cross-functional  systems  by  a  "carrot  and 
stick"  approach,  providing  subsidies  to  program  managers  who  develop  them  and  taxing 
those  who  do  not.  The  subsidy  could  involve  a  direct  transfer  of  funds  to  the  program 
from  a  special  account  established  for  such  a  purpose  and  managed  by  G-TTC.  It  could 
define  a  certain  level  of  technical  or  management  support  from  G-TTC.  Finally,  it  could 
entail  some  form  of  lower  communication  charges  for  using  the  Hybrid  Data  Network, 
or  other  parts  of  the  information  architecture  (below).  The  "taxes"  would  be  largely  the 
opposite  of  the  possibilities  for  subsidies. 

E.  DEVELOPING  THE  INFORMATION  ARCHITECTURE 

The  information  architecture  is  quite  different  from  application  systems.  Rather 
than  benefitting  one  group  of  end  users,  the  information  architecture  is  a  special 
infrastructure  which  benefits  the  entire  organization.  It  is  of  a  magnitude  that  can  benefit 
from  economies  of  scale  by  centralizing.  And  it  requires  centralized  planning  and  control 
in  order  to  provide  services  to  all  users.  A  robust  information  architecture  is  so  likely 
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to  be  prohibitively  expensive  for  any  single  system,  yet  would  prove  very  beneficial  to 
system  developers  once  implemented. 

The  information  architecture  is  clearly  a  special  case,  which  should  be  provided  on 
an  organization-wide  basis.  It  should  be  funded  and  managed  as  a  public  good,  an 
element  of  society's  infrastructure.  The  Office  of  Command,  Control,  and 
Communications  (G-T)  should  establish  standards  for  the  architecture,  obtain  funding  for 
it,  and  maintain  control  over  it,  providing  access  to  it  for  all  system  developers.  This 
approach  has  several  benefits.  One  of  the  largest  comes  from  the  network  externality  of 
economic  theory.  If  a  telephone  network  has  access  to  only  a  hundred  subscribers,  it  is 
worth  very  little  to  a  potential  subscriber  to  join  the  network  because  of  the  limited 
number  of  others  that  can  be  reached.  Yet  if  the  network  has  a  hundred  million 
subscribers,  or  at  least  reaches  all  persons  with  whom  the  potential  subscriber  wants  to 
communicate,  it  is  worth  a  great  deal  more.  The  Hybrid  Data  Network,  as  a  cornerstone 
of  the  Coast  Guard's  information  architecture,  should  be  controlled  by  a  central  authority 
within  the  agency  for  the  good  of  the  whole  organization. 

Another  benefit  from  the  information  architecture  is  in  reduced  costs  for  developers 
of  cross-functional  systems,  or  even  stovepipe  applications.  By  relying  on  existing 
standards  in  tlie  area  of  telecommunications,  database,  and  user  interface,  developers 
would  be  able  to  dramatically  reduce  the  time  and  cost  required  for  new  systems.  It  is 
not  at  all  unreasonable  to  expect  that  such  development  efforts  would  be  less  than  half 
as  costly  as  completely  independent  systems. 
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Finally,  the  Coast  Guard  should  formalize  an  initiative  that  is  growing  within  G- 
MIM.  That  office  is  developing  the  contract  specifications  for  the  new  Marine  Safety 
Network.  They  hope  it  can  be  used  as  a  common  contract  vehicle  for  MIS  projects  by 
all  program  managers.  This  could  significantly  reduce  some  of  the  up-front  contracting 
work,  allowing  system  developers  to  concentrate  more  on  the  system  requirements,  rather 
than  the  mechanics  of  how  to  acquire  it. 
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VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


Infonnation  technology,  well  implemented,  can  clearly  provide  major  benefits  to  the 
Coast  Guard.  Existing  systems  do  not  provide  the  organization  with  a  smooth  information 
flow.  Cross -functional  systems,  based  on  a  robust  information  architecure,  will 
dramatically  improve  infonnation  flow,  reduce  redundant  use  of  personnel  time  for  data 
entry,  reduce  duplication  of  effort  across  programs,  and  improve  availability  of 
infonnation  to  decision  makers. 

A.  CONCLUSIONS 

Information  does  not  flow  smoothly,  but  follows  a  torturous  path  through  the 
organization.  It  is  frequently  not  available  to  employees  who  could  use  it  to  make  better 
decisions  for  the  organization  as  a  whole. 

Existing  systems  suffer  from  a  large  degree  of  overlap  and  inconsistency  in 
infonnation  content,  but  offer  no  means  for  eliminating  the  overlap  or  reconciling  the 
inconsistencies.  This  forces  repetitive  data  entry  into  separate  systems,  and  increases 
workload  and  frustration  for  field  personnel. 

Existing  systems  suffer  from  poor  connectivity  and  user  interfaces,  which  combine 
to  make  it  difficult  to  retrieve  information.  As  a  result,  decision  makers  do  not  get 
information  they  should  have.  Others  are  forced  to  spend  significant  time  and  effort,  both 
in  learning  how  to  retrieve  information,  and  in  actually  performing  the  process. 
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Cross-functional  systems  offer  a  means  of  correcting  many  of  these  problems.  By 
improving  the  flow  and  availability  of  information  within  the  organization,  they  offer 
opportunities  to  improve  effectiveness  of  the  existing  organizational  structure  by  re¬ 
designing  processes.  Further,  they  offer  the  opportunity  to  re-engineer  the  organization 
to  better  serve  the  public. 

B.  RECOMMENDATIONS 
1.  Future  Development 

The  Coast  Guard  should  aggressively  pursue  its  stated  policy  of  developing 
cross-functional  systems.  Specifically,  it  should  develop  a  cross-functional  Operations 
Information  System  (OIS),  as  described  in  Chapter  V. 

OIS,  and  other  cross-functional  systems,  should  rely  on  a  robust  information 
architecture.  This  should  consist  of  a  common  telecommunications  network,  a  common 
user  interface,  and  a  small  number  of  common  databases.  Development  and  maintenance 
of  the  information  architecture  should  be  centralized,  as  described  in  Chapter  VI. 

Application  systems  should  be  cross-functional  whenever  possible,  and  this 
should  be  encouraged  as  part  of  the  budget  process  with  some  form  of  subsidy,  as 
described  in  Chapter  VI.  Similarly,  stovepipe  systems  should  be  discouraged,  through 
some  form  of  tax.  Application  systems  should  be  developed  and  maintained  in  a 
decentralized  fashion  as  much  as  possible.  New  applications  should  be  implemented  in 
a  scheme  of  phased  deliverables,  tying  into  existing  cross-functional  systems  a  piece  at 


2.  Existing  System  Upgrades 

Existing  applications  should  be  upgraded,  because  of  the  long  lead  time  until 
they  can  be  incorporated  into  a  cross-functional  system.  However,  the  upgrades  should 
not  disregard  the  potential  for  cross-functionality.  Rather,  upgrades  can  pave  the  way  for 
smooth  transitions  to  eventual  cross-functional  systems.  Specific  recommendations  follow. 

a.  Data  Storage  and  Retrieval 

Transition  the  data  from  file  processing  systems  to  database  management 
systems.  Use  one  of  the  Coast  Guard’s  standard  DBMS  packages,  either  Progress™  or 
Oracle^'’’.  Rely  on  die  Data  Element  Naming  Conventions  when  designing  the  schema 
for  the  upgraded  database.  In  this  way,  transferring  the  data  to  a  cross-functional 
database  later  will  be  significantly  easier. 

b.  Telecommunications  Solutions 

Transition  from  independent  telecommunications  solutions  to  the  Hybrid 
Data  Network.  Build  support  for  the  HDN  into  applications,  and  hide  the  task  of 
establishing  connections  to  the  central  site  from  the  user. 

c.  User  Interface  Design 

Defme  a  style  guide  for  applications.  This  should  rely  on  menu-driven 
interfaces,  using  the  soft-key  approach  to  defining  the  function  keys.  Menu  structures 
should  be  similar,  and  thus  familiar,  between  applications.  Future  applications  should  be 
written  to  the  XVT  API,  providing  the  additional  ease  of  use  of  a  Graphical  User 
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Interface  when  the  end  user's  workstation  supports  it.  The  combination  of  style  guides 
and  GUIs  will  greatly  enhance  user's  productivity. 

Transition  from  the  SARMIS  approach,  which  presents  users  one  question 
at  a  time  on  screen,  to  something  like  the  SIMS/ELT  approach.  This  presents  the  user 
with  a  form  containing  logically  related  data  elements,  allowing  faster  data  entry  and 
better  understanding  of  how  much  of  the  task  has  been  completed. 

Build  support  for  integrated  sensors  and  flexible  input  devices  into  future 
applications.  The  key  is  to  integrate  information  systems  into  the  operating  units'  work 
patterns  as  closely  as  possible,  so  that  their  attention  may  be  focused  on  conducting 
operations  rather  than  on  gathering  or  reporting  information  in  support  of  operations. 

d.  Distributed  Processing 

Employ  the  processing  power  of  the  Standard  Workstation  to  provide  the 
user  interface,  establish  connections,  and  maintain  local  databases.  Avoid  applications 
that  treat  the  CGSW  as  a  dumb  terminal. 
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APPENDIX  A:  U.  S.  COAST  GUARD  ORGANIZATION 


The  following  pages  describe  organizational  relationships  within  and  affecting  the 
Coast  Guard.  Figure  19  shows  the  Department  of  Transportation  organization.  Figure 
20  shows  the  operational  chain  of  command  in  the  Coast  Guard.  Figure  21  shows  the 
staff  organization  at  Coast  Guard  Headquarters. 
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Secretary  of  Transportation 
Deputy  Secretary 


Figure  19:  Department  of  Transportation  organization. 
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Commandant 


Figure  20:  U.  S.  Coast  Guard  organization. 
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APPENDIX  B;  CROSS-FUNCTIONAL  DATABASE  PROTOTYPE 


This  Appendix  contains  a  summary  of  a  database  project  done  by  the  author  and 
another  student  (Glidden  and  Marsh,  Dec  90).  It  was  designed  as  a  prototype  cross¬ 
functional  system  to  support  two  of  the  Coast  Guard’s  missions,  Search  and  Rescue  (SAR) 
and  Enforcement  of  Laws  and  Treaties  (ELT). 

Tables  13  and  14  in  Chapter  VI  describe  the  78%  overlap  between  the  information 
in  the  Report  of  Boarding,  form  CG-4100,  and  the  SAR  Unit  Case  Folder,  form  CG- 
16130.  At  first  thought,  it  is  hard  to  believe  that  nearly  80%  of  the  data  in  the  two 
systems  is  the  same.  However,  when  one  thinks  about  the  type  of  information  the  Coast 
Guard  collects  in  terms  of  data  objects,  the  reason  for  the  overlap  becomes  clear.  This 
list  describes  the  objects: 

INCIDENT  This  is  the  main  object  in  this  prototype.  The  bottom  line  is  that  the 
Coast  Guard  collects  all  this  information  from  field  units  and  stores  it  in 
a  central  computer  because  something  happened.  It  happened 
somewhere,  and  at  a  certain  time  and  date.  When  translated  into 
relations  and  relationships,  the  data  occupies  roughly  24  data  items  in 
three  tables. 

WEATHER  Every  incident  has  a  weather  report  associated  with  it.  Roughly  20  data 
items  in  a  single  table. 

PERSON  Nearly  every  incident  involves  people,  either  as  crewmembers  of  a 
boarded  vessel,  or  aboard  SAR  case  subjects,  or  both.  Roughly  25  fields 
in  two  tables. 

VESSEL  Nearly  every  incident  also  involves  a  boat.  Roughly  34  data  items  in  a 
single  table. 
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SAR  CASE  Information  that  is  unique  to  SAR  cases:  unit  case  number,  nature  of 
distress,  lives  lost  and  saved.  Roughly  10  data  items  in  two  tables. 

BOARDING  Information  that  is  unique  to  law  enforcement  boardings:  boarding  report 
number,  name  and  rank  of  boarding  officer,  violation  codes,  and  remarks. 
Roughly  19  data  items  in  four  tables. 


The  following  pages  are  key  excerpts  from  the  design  documents  for  this  simple 
integrated  system,  describing  the  data  objects,  the  relational  diagram  (Figure  22),  and  the 
data  dictionary. 
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Requirements 


I.  Data  Requirements 

We  defined  six  major  objects  in  the  environment  of  a  Coast  Guard  field  unit 
tracking  operational  data,  which  are: 

•  The  VESSELS  which  are  the  subject  of  operations. 

•  The  PERSONnel  which  are  the  subject  of  operations. 

•  The  INCIDENTS  which  operations  involve. 

•  The  WEATHER  at  the  time  of  an  incident. 

•  The  SAR  CASEs  which  the  unit  conducts. 

•  The  BOARDINGS  which  the  unit  conducts. 

In  defining  the  objects  involved  in  this  application,  we  began  by  considering,  from 
our  personal  exf)erience  in  the  field,  what  general  categories  of  information  were  involved 
in  the  SAR  and  LE  missions.  It  was  clear  that  both  normally  involve  vessels,  although 
some  few  missions  do  not;  likewise,  nearly  all  missions  involve  people.  Also  common 
to  both  mission  areas  are  weather  information  and  general  descriptive  data,  such  as 
position,  date,  and  time.  These  four  objects  are  part  of  nearly  every  mission;  the 
mission-specific  objects  include  details  of  the  damage  and  nature  of  distress,  for  SAR 
cases,  and  of  the  boarding  and  any  citations,  for  LE  cases. 

We  validated  these  object  definitions  by  examination  of  the  paper  forms  presently 
in  use:  a  SAR  case  folder,  form  CG-16130,  and  a  Report  of  Boarding,  form  CG-4100. 
These  forms  arc  included  as  Appendix  F. 
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INJURIES 


Figure  22;  Relational  Diagram. 
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Relation  Definition: 
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